Netty如何解决的大量客户端连接上的线程同步问题?
本篇文章大概700字，阅读时间大约4分钟
本篇文章是对前面Netty线程图像相关文章的一个重新总结，并修改了一些错误，还是希望用面试题的形式来全面总结Netty的设计思想和使用的细节，本文主要是重点review了Netty的骚设计——即如何解决的大量客户端连接上的线程同步问题，并且希望能运用到我们自己的业务代码里
前面分析了很多次，大体知道，Netty通过触发I/O事件将Selector从JDK中抽象出来，消除了所有本来将需要手动编写的NIO线程派发代码。在Netty内部会为每个新建的客户端Channel分配一个EventLoop（NIO线程、或者泛化的说是I/O线程），用以处理Channel上的所有I/O事件，前面分析了NIO线程和客户端连接是一对多的关系，即一个客户端连接只能绑定一个NIO线程，反过来一个NIO线程可以绑定多个客户端连接，如下图，侵删：
每个EventLoop（I/O线程）可以处理如下事件:
1、继续注册感兴趣的I/O事件
2、将已经触发的I/O事件通过pipeline的事件传播机制，派发给用户配置的或者默认的一些业务处理单元——ChannelHandler
3、安排进一步的动作
一定要理解EventLoop：这个对象本身聚合了一个永远不会改变的JDK 的Thread对象，在其整个生命周期内，该线程会驱动该EventLoop里的一切动作，包括处理当前绑定的Channel（网络连接）上的所有I/O事件，当然后续会知道，还能处理一些异步任务，每一个EventLoop都是如此。
就是因为这个简单而强大的设计，巧妙的避免了多个I/O线程共享同一个Channel的场景出现。使得每个Channel的pipeline中的处理单元，能够被串行的执行，同时多个channel-pipeline在宏观上又是并行（发）执行的。
这种设计实际上消除了对于一个网络连接中I/O事件同步的需要。且也不缺乏并行性，尤其在多核处理器里，更是明显，这就是大名鼎鼎的局部串行无锁化线程池的设计思想，业务代码里可以参考。
END
点亮在看，你最好看
~
点阅读原文,获得更多精彩内容