netty中的Channelhandler的执行和堵塞
【netty中的Channelhandler的执行和堵塞】通常 ChannelPipeline 中的每一个 ChannelHandler 都是通过它绑定的EventLoop（I/O 线程）来处理传递给它的事件的。而同一个EventLoop可能会分配给多个Handler 所以至关重要的是不要阻塞这个线程，因为这会对整体的 I/O 处理产生负面的影响。但有时可能需要与那些使用阻塞 API 的遗留代码进行交互。对于这种情况， ChannelPipeline 有一些接受一个 EventExecutorGroup 的 add()方法。如果一个事件被传递给一个自定义的 EventExecutor-Group，它将被包含在这个 EventExecutorGroup 中的某个 EventExecutor 所处理，从而被从该Channel 本身的 EventLoop 中移除。对于这种用例， Netty 提供了一个叫 DefaultEventExecutorGroup 的默认实现。netty中该方法的说明如下：
/**
* Inserts {@link ChannelHandler}s at the last position of this pipeline.
*
* @param group the {@link EventExecutorGroup} which will be used to execute the {@link ``ChannelHandler}s
* methods. 该EventExecutorGroup会被用来执行该ChannelHandler的方法
* @param handlers the handlers to insert last
*
*/
ChannelPipeline addLast(EventExecutorGroup group, ChannelHandler... handlers);
也是说，一个Channel对应的所有ChannelHandler实例原来对传递过来的事件处理方法（ 例如ChannelRead() 方法）是由分配给该Channel的Eventloop（I/O 线程）所绑定的线程来调用处理的。当为某个handler（该handler处理业务逻辑耗时较长或阻塞）指定单独EventExecutorGroup，当需要处理耗时的业务逻辑操作时，就不需要分配给ChannelEventloop（I/O 线程）来进行操作，I/O线程也就不会阻塞，可以处理其他的Channel 的I/O操作 （Eventloop（I/O 线程）是复用的，它可以被分配给多个Channel)
推荐阅读
- 热闹中的孤独
- JS中的各种宽高度定义及其应用
- 我眼中的佛系经纪人
- 《魔法科高中的劣等生》第26卷（Invasion篇）发售
- Android中的AES加密-下
- 放下心中的偶像包袱吧
- C语言字符函数中的isalnum()和iscntrl()你都知道吗
- C语言浮点函数中的modf和fmod详解
- C语言中的时间函数clock()和time()你都了解吗
- 如何在Mac中的文件选择框中打开系统隐藏文件夹