Apache MINA 线程模型配置

　1、禁止缺省的ThreadModel设置

　　MINA2.0及以后版本已经没有ThreadModel了，如果使用这些版本的话，可以跳过本节。

　　ThreadModel设置是在MINA1.0以后引入的，但是使用ThreadModel增加了配置的复杂性，推荐禁止掉缺省的TheadModel配置。

　　IoAcceptor acceptor = ...;

　　IoServiceConfig acceptorConfig = acceptor.getDefaultConfig();

　　acceptorConfig.setThreadModel(ThreadModel.MANUAL);

　　注意在相关指南中，假定你已经如本节所说的禁止了ThreadModel的缺省配置。

　　2、配置I/O工作线程的数量

　　这节只是NIO实现相关的，NIO数据包以及虚拟机管道等的实现没有这个配置。

　　在MINA的NIO实现中，有三种I/O工作线程：

　　>>Acceptor线程 接受进入连接，并且转给I/O处理器线程来进行读写操作。每一个SocketAcceptor产生一个Acceptor线程，线程的数目不能配置。

　　>>Connector线程 尝试连接远程对等机，并且将成功的连接转给I/O处理器线程来进行读写操作。每一个SocketConnector产生一个Connector线程，这个的数目也不可以配置。

　　>>I/O处理器线程 执行实际上的读写操作直到连接关闭。每一个SocketAcceptor或SocketConnector都产生它们自己的I/O处理线程。这个数目可以配置，缺省是1。

　　因此，对于每个IoService，可以配置的就是I/O处理线程的数目。下面的代码产生一个有四个I/O处理线程的SocketAcceptor。

　　IoAcceptor acceptor = new SocketAcceptor(4, Executors.newCachedThreadPool());

　　没有单凭经验来决定I/O处理线程数目的方法，大概可以从1开始增加。

　　IoAcceptor acceptor = new SocketAcceptor(Runtime.getRuntime().availableProcessors() + 1, Executors.newCachedThreadPool());

　　3、增加一个ExecutorFilter到IoFilterChain中

　　ExecutorFilter是一个IoFilter，用于将进入的I/O事件转到一个 java.util.concurrent.Executor实现。事件会从这个Executor转到下一个IoFilter，通常是一个线程池。可以在 IoFilterChain的任何地方增加任意数目的ExecutorFilter，实现任何类型的线程模型，从简单的线程池到复杂的SEDA。

　　到现在为止我们还没有增加ExecutorFilter，如果没有增加ExecutorFilter，事件会通过方法调用转到一个 IoHandler，这意味着在IoHandler实现中的业务逻辑会在I/O处理线程里运行。我们叫这种线程模型为"单线程模型"。单线程模型可以用来就会低反应网络应用程序，受CPU限制的业务逻辑（如，游戏服务器）。

　　典型的网络应用需要一个ExecutorFilter插入到IoFilterChain中，因为业务逻辑和I/O处理线程有不同的资源使用模式。如果你用IoHandler的实现来执行数据库操作，而没有增加一个ExecutorFilter的话，那么，你整个服务器会在执行数据库操作的时候锁定，特别是数据库性能低的时候。下面的例子配置一个IoService在一个新的IoSession建立时增加一个ExecutorFilter。

　　IoAcceptor acceptor = ...;

　　DefaultIoFilterChainBuilder filterChainBuilder = acceptor.getDefaultConfig().getFilterChain();

　　filterChainBuilder.addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool());

　　这里要注意ExecutorFilter没有管理特定的Executor的生命周期，当完成时，需要关闭所有特定Executor的工作线程。

　　ExecutorService executor = ...;

　　IoAcceptor acceptor = ...;

　　DefaultIoFilterChainBuilder filterChainBuilder = acceptor.getDefaultConfig().getFilterChain();

　　filterChainBuilder.addLast("threadPool", new ExecutorFilter(executor);

　　// Start the server.

　　acceptor.bind(...);

　　// Shut down the server.

　　acceptor.unbind(...);

　　executor.shutdown();

　　使用一个ExecutorFilter通常不意味着要用一个线程池，对于Executor的实现没有任何限制。

　　4、应该把ExecutorFilter放在IoFilterChain的什么地方

　　这个要根据于具体应用的情况来定。如果一个应用有一个ProtocolCodecFilter实现和一个常用的有数据库操作的IoHandler实现的话，那么就建议在ProtocolCodecFilter实现的后面增加一个ExecutorFilter，这是因为大部分的协议解码实现的性能特性是受CPU限制的，和I/O处理线程是一样的。

　　IoAcceptor acceptor = ...;

　　DefaultIoFilterChainBuilder filterChainBuilder = acceptor.getDefaultConfig().getFilterChain();

　　// Add CPU-bound job first,

　　filterChainBuilder.addLast("codec", new ProtocolCodecFactory(...));

　　// and then a thread pool.

　　filterChainBuilder.addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool());

　　5、选择IoService的线程池类型时要小心

　　Executors.newCachedThreadPool()经常是IoService首选的。因为如果使用其它类型的话，可能会对 IoService产生不可预知的性能方面的影响。一旦池中的所有线程都在使用中，IoService会在向池尝试请求一个线程时开始锁定，然后会出现一个奇怪的性能下降，这有时是很难跟踪的。

　　6、不推荐IoServices和ExecutorFilters共享一个线程池

　　你可以想让IoServices和ExecutorFilters共享一个线程池，而不是一家一个。这个是不禁止的，但是会出现很多问题，在这种情况下，除非你为IoServices建立一个缓冲线程池。