ProtocolCodecFilter
网络传输的内容其实本质是一个二进制流，但是我们的业务功能不会，或者说不应该去直接操作二进制流。MINA默认向IoHandler传入的message是一个ByteBuffer，如果我们直接在IoHandler操作ByteBuffer，会导致大量协议分析的代码和实际的业务代码混杂在一起。最适合的做法，就是在IoFilter把ByteBuffer转换成String或者JavaBean，ProtocolCodecFilter正是这样的一个功能的过滤器。
使用ProtocolCodecFilter很简单，我们只要把ProtocolCodecFilter加入到FilterChain就可以了，但是我们需要提供一个ProtocolCodecFactory。其实ProtocolCodecFilter仅仅是实现了过滤器部分的功能，它会将最终的转换工作，交给从ProtocolCodecFactory获得的Encode和Decode。如果我们需要编写自己的ProtocolCodec，就应该从ProtocolCodecFactory入手。MINA内置了几个ProtocolCodecFactory，比较常用的就是ObjectSerializationCodecFactory和TextLineCodecFactory。
ObjectSerializationCodecFactory是Java Object序列化之后的内容直接跟ByteBuffer互相转化，比较适合两端都是Java的情况使用。TextLineCodecFactory就是String跟ByteBuffer的转化，说白了就是文本，例如你要实现一个SMTP服务器，或者POP服务器，就可以使用它。而笔者的实际使用，大多数情况都是使用
TextLineCodecFactory。
这里提及一下IoFilter的顺序问题，IoFilter是有加入顺序的，例如，先加入LoggingFilter再加入ProtocolCodecFilter，和先加入ProtocolCodecFilter再加入LoggingFilter的效果是不一样的，前者LoggingFilter写入日志的内容是ByteBuffer，而后者写入日志的是转换后具体的类，例如String。实际使用的时候，一定要处理好过滤器的顺序。
ExecutorFilter
另一个重要的过滤器就是ExecutorFilter。这里，我需要先说明一下MINA的线程工作模式，MINA默认是单线程处理所有客户端的消息，也就是说，即使你在一台8CPU的机器上面跑，可能也只用到一个CPU，另外，如果某次消息处理太耗时，就会导致其他消息等待，整体的吞吐量下降。很多朋友抱怨MINA的性能差，其实是因为他们没有加入ExecutorFilter的缘故。ExecutorFilter设计的很精巧，大家可以仔细阅读一下源代码，它会将同一个连接的消息合并起来按顺序调用，不会出现两个线程同时处理同一个连接的情况。
1.IoAcceptor acceptor = ...;
2.IoServiceConfig acceptorConfig = acceptor.getDefaultConfig();
3.acceptorConfig.setThreadModel(ThreadModel.MANUAL);
优化指南
MINA默认配置的性能并不是很高的，部分原因是MINA目前还保留初期版本的架构，另外一个原因是因为JVM的发展。
1.IoAcceptor acceptor = new SocketAcceptor(Runtime.getRuntime().availableProcessors() + 1, Executors.newCachedThreadPool());
首先我们关闭默认的ThreadModel设置 ThreadModel是一个很简单的线程实现，用于IoService。但是它实在太弱，以至于在并发环境产生大量问题。在MINA 2.0中，ThreadModel直接被取消。你应该使用ExecutorFilter来实现线程。
1.acceptor.getDefaultConfig().getFilterChain().addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool());
然后我们增加I/O处理线程
每一个Acceptor/Connector都使用一个线程来处理连接，然后把连接发送给I/O processor进行读写操作，我们只可以修改I/O processor使用的线程数，用以下代码设置 当然是要将ExecutorFilter加入，上文已经很详细地描述了 笔者在开发过程中，多次遇到OutOfMemoryError，经过研究之后才发现原因。MINA默认是使用direct memory实现ByteBuffer池的方案（以下简称direct buffer），通过JNI在内存开辟一段空间来使用，该方案在早期的MINA版本中是一个非常好的特性，那是因为MINA开发初期，JVM并没有现在的强大，带有池效果的direct buffer性能比较好。但是当我们使用-Xms -Xmx等指令增加JVM可使用的内存，那仅仅增加了堆的内存空间，而direct memory的空间并没有增加，导致MINA实际使用的时候经常出现OutOfMemoryError。如果你的确想使用direct memory，可以通过-XX:MaxDirectMemorySize选项来设置。不过笔者不建议这样做，因为最新的测试表明，在现代的JVM里面，direct memory比堆的表现更差。这里可能有读者会觉得奇怪，为什么不用池，而要用堆呢，而且还需要gc。那是因为现在的JVM gc能力已经很强了，而且在并发环境里面，pool的同步也是一个性能的问题。我们可以通过这样的代码进行设置 MINA 2.0已经默认把直接内存分配改成堆，为了提供最好的性能和稳定性。
1.ByteBuffer.setUseDirectBuffers(false);
2.ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
最后一条优化技巧就是，把你的应用部署在Linux上，并且打开Java NIO使用Linux epoll的功能。可能你还没听过epoll，但是你应该听过Lighttpd