傻大方提要：【绝！真就一文全懂！Netty线程模型+启动详细分析+内存管理】使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等；需要具备其它的额外技能做铺垫，例如熟悉Java多线程编程，因为NIO编程涉及到Reactor模式，你必须对多线程和...
按关键词阅读：
简介Netty是一款异步的事件驱动的网络应用程序框架 ， 支持快速地开发可维护的高性能的面向协议的服务器和客户端 。 它提供了对TCP、UDP和文件传输的支持 ， 作为一个异步NIO框架 ， Netty的所有IO操作都是异步非阻塞的 ， 通过Future-Listener机制 ， 用户可以方便的主动获取或者通过通知机制获得IO操作结果 。
文章插图
为什么用Netty不用NIO
- NIO的类库和API繁杂 ， 使用麻烦 ， 你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等；
- 需要具备其它的额外技能做铺垫 ， 例如熟悉Java多线程编程 ， 因为NIO编程涉及到Reactor模式 ， 你必须对多线程和网路编程非常熟悉 ， 才能编写出高质量的NIO程序；
- 可靠性能力补齐 ， 工作量和难度都非常大 。 例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等等 ， NIO编程的特点是功能开发相对容易 ， 但是可靠性能力补齐工作量和难度都非常大；
- JDK NIO的BUG ， 例如epoll bug ， 它会导致Selector空轮询 ， 最终导致CPU 100% 。 官方声称在JDK1.6版本的update18修复了该问题 ， 但是直到JDK1.7版本该问题仍旧存在 ， 只不过该bug发生概率降低了一些而已 ， 它并没有被根本解决 。
文章插图3种reactor模式单线程的reactor模式
文章插图Reactor线程是个多面手 ， 负责多路分离套接字 ， Accept新连接 ， 并分派请求到处理器链中 。 该模型适用于处理器链中业务处理组件能快速完成的场景 。 不过 ， 这种单线程模型不能充分利用多核资源 ， 所以实际使用的不多 。
性能缺陷：
- 一个NIO线程同时处理成百上千的链路 ， 性能上无法支撑 。 即便NIO线程的CPU负荷达到100% ， 也无法满足海量消息的编码、解码、读取和发送；
- 当NIO线程负载过重之后 ， 处理速度将变慢 ， 这会导致大量客户端连接超时 ， 超时之后往往进行重发 ， 这更加重了NIO线程的负载 ， 最终导致大量消息积压和处理超时 ， NIO线程会成为系统的性能瓶颈；
- 可靠性问题 。 一旦NIO线程出现错误 ， 或者进入死循环 ， 会导致整个系统通讯模块不可用 ， 不能接收和处理外部信息 ， 造成节点故障 。
文章插图Reactor多线程模型的特点：
- 有专门一个NIO线程-Acceptor线程用于监听服务端 ， 接收客户端的TCP连接请求；
- 网络IO操作-读、写等由一个NIO线程池负责 ， 线程池可以采用标准的JDK线程池实现 ， 它包含一个任务队列和N个可用的线程 ， 由这些NIO线程负责消息的读取、解码、编码和发送；
- 1个NIO线程可以同时处理N条链路 ， 但是1个链路只对应1个NIO线程 ， 防止发生并发操作问题 。
主从reactor多线程模型
文章插图注册accepter事件处理器到mainReactor线程池中 ， 这样mainReactor会监听客户端向服务端发起的连接请求
当客户端向服务端发起连接请求时 ， mainReactor监听到了该请求将事件派发给acceptor事件处理器进行处理 ， 可通过accept方法获得连接socketChannel ， 然后将socketChannel传递给subReactor线程池
subReactor线程池分配一个subReactor线程给这个SocketChannel ， 监听I/O的read、write操作 ， 相关业务逻辑的处理交给工作线程池来完成
Netty的线程模型
文章插图当NettyServer启动时候会创建两个NioEventLoopGroup线程池组 。
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111J293N2020.html
标题：绝！真就一文全懂！Netty线程模型+启动详细分析+内存管理