Netty并发优化之ExecutionHandler
上文《Netty框架入门》说到：如果业务处理handler耗时长，将严重影响可支持的并发数。
针对这一问题，经过学习，发现了可以使用ExecutionHandler来优化。
先来回顾一下没有使用ExecutionHandler优化的流程：
1）Boss线程（接收到客户端连接）->生成Channel->交给Worker线程池处理。
2）某个被分配到任务的Worker线程->读完已接收的数据到ChannelBuffer->触发ChannelPipeline中的ChannelHandler链来处理业务逻辑。
注意：执行ChannelHandler链的整个过程是同步的，如果业务逻辑的耗时较长，会将导致Work线程长时间被占用得不到释放，从而影响了整个服务器的并发处理能力。
一、引入ExecutionHandler优化
//HttpServerPipelineFactory.java
private final ExecutionHandler executionHandler = new ExecutionHandler(
new OrderedMemoryAwareThreadPoolExecutor(16, 1048576, 1048576));
public class HttpServerPipelineFactory implements ChannelPipelineFactory {
@Override
public ChannelPipeline getPipeline() throws Exception {
ChannelPipeline pipeline = Channels.pipeline();
pipeline.addLast("decoder", new HttpRequestDecoder());
pipeline.addLast("encoder", new HttpResponseEncoder());
pipeline.addLast("execution", executionHandler);
pipeline.addLast("handler", new HttpServerHandler());
return pipeline;
}
}
当我们引入ExecutionHandler后，原本同步的ChannelHandler链在经过 ExecutionHandler后就结束了，它会被ChannelFactory的worker线程池所回收，而剩下的ChannelHandler链将由ExecutionHandler的线程池接手处理。
对于ExecutionHandler需要的线程池模型，Netty提供了两种可选：
1） MemoryAwareThreadPoolExecutor 通过对线程池内存的使用控制，可控制Executor中待处理任务的上限（超过上限时，后续进来的任务将被阻塞），并可控制单个Channel待处理任务的上限，防止内存溢出错误。但是它不维持同一Channel的ChannelEvents秩序，当经过ExecutionHandler后的ChannelHandler链中有不止一个Handler时，这些事件驱动存在混乱的可能。例如：
----------------------------------------> Timeline -------------------------------------> Thread X: --- Channel A (Event 2) --- Channel A (Event 1) -----------------------------> Thread Y: --- Channel A (Event 3) --- Channel B (Event 2) --- Channel B (Event 3) ---> Thread Z: --- Channel B (Event 1) --- Channel B (Event 4) --- Channel A (Event 4) --->
2） OrderedMemoryAwareThreadPoolExecutor 是 MemoryAwareThreadPoolExecutor 的子类。除了MemoryAwareThreadPoolExecutor 的功能之外，它还可以保证同一Channel中处理的事件流的顺序性（不同Channel使用不同的key保持事件顺序），这主要是控制事件在异步处理模式下可能出现的错误事件顺序，但它并不保证同一 Channel中的事件都在一个线程中执行（通常也没必要）。例如：
----------------------------------------> Timeline ---------------------------------------->
Thread X: --- Channel A (Event 1) --. .-- Channel B (Event 2) --- Channel B (Event 3) --->
\ /
X
/ \
Thread Y: --- Channel B (Event 1) --' '-- Channel A (Event 2) --- Channel A (Event 3) --->
二、具有可伸缩性的OrderedMemoryAwareThreadPoolExecutor使用策略
在大多数情况下，我们会使用OrderedMemoryAwareThreadPoolExecutor，它的构造函数要求我们提供线程池的大小，在上面的代码中，我们使用了16这个具体的值，是一种很不好的写法，通常情况下，我们会使用配置文件使之可变，但是在实际部署时，并不能保证实施人员能很好的去调整，故提供如下的一种写法：
double coefficient = 0.8; //系数 int numberOfCores = Runtime.getRuntime().availableProcessors(); int poolSize = (int)(numberOfCores / (1 - coefficient));
我们可以使用poolSize取代OrderedMemoryAwareThreadPoolExecutor(16, 1048576, 1048576)中的那个16，因为当一个系统被开发出来后，它是CPU密集型还是IO密集型是可评估的，通过评估其密集型，调整系数即可：CPU密集型接近0，IO密集型接近1。
