netty从线程模型、内存管理、事件处理和bug修复四层面系统性重构java nio：采用主从reactor分离i/o与业务逻辑；bytebuf自动索引管理、内存池复用及零拷贝提升性能；pipeline+handler统一事件驱动；自研epolleventloop绕过jdk空轮询等bug。
Netty对原生Java NIO的封装不是简单包装，而是从线程模型、内存管理、事件处理和Bug修复四个层面做了系统性重构，让高并发网络通信变得可靠且可维护。
主从Reactor线程模型替代单Selector轮询
原生NIO需手动维护一个Selector并不断轮询就绪事件，所有连接建立、读写、异常都挤在同一线程里，容易阻塞或争用。Netty引入主从Reactor分离机制：
- Boss Group（主Reactor）：只做一件事——监听OP_ACCEPT，接受新连接后立即移交Worker Group，不参与任何I/O处理
- Worker Group（从Reactor）：每个线程绑定独立Selector，专责已连接Channel的OP_READ/OP_WRITE，天然支持多核并行
- 业务逻辑可进一步卸载到独立业务线程池，避免耗时操作（如DB查询、JSON解析）拖慢网络线程
ByteBuf替代ByteBuffer，解决内存与拷贝痛点
原生ByteBuffer需手动flip/clear、容量固定、无引用计数、堆外内存申请成本高。Netty的ByteBuf设计直击这些短板：
- 自动管理读写索引，无需flip/clear；支持动态扩容（如Unpooled.buffer()）
- 提供PooledByteBufAllocator内存池，默认复用直接内存块，大幅降低GC压力
- 零拷贝能力落地：CompositeByteBuf组合多个缓冲区不复制数据；FileRegion调用sendfile系统调用跳过用户态拷贝；slice()和duplicate()生成共享底层内存的视图
统一事件驱动模型屏蔽底层细节
原生NIO中Channel注册、SelectionKey状态判断、Buffer分配回收、半包/粘包处理全靠手写，极易出错。Netty通过Pipeline+Handler机制解耦：
- 每个Channel绑定唯一ChannelPipeline，事件（connect、read、exceptionCaught等）按顺序流经添加的ChannelHandler
- 开箱即用的编解码器：LengthFieldBasedFrameDecoder自动拆帧防粘包；StringEncoder/StringDecoder处理文本；ProtobufEncoder/Decoder支持序列化
- 异常统一由ExceptionCaughtHandler捕获，连接关闭、资源清理自动触发，无需手动cancel key或close channel
绕过JDK NIO底层Bug，提升生产稳定性
原生NIO在Linux上存在Epoll空轮询Bug（JDK-6403933），导致CPU 100%，只能靠重建Selector临时规避。Netty的应对方式更彻底：
- 针对Linux平台，使用自研EpollEventLoop，直接封装epoll_ctl/epoll_wait系统调用，完全脱离JDK原生EPollSelectorImpl
- 对就绪事件链表做双重校验，确保select()返回前真实有事件就绪，从根源杜绝空轮询
- Windows平台则使用NioEventLoop，但同样增强超时控制与异常恢复逻辑，避免Selector失效后服务不可用
