网络框架与 Netty：从 Reactor 到零拷贝

为什么需要 Netty、它解决了什么、核心机制与同类对比

0. 读前必读：为什么需要 Netty（衔接 Part01 I/O 模型）

在 Part01 我们讲过 I/O 模型的演进：BIO（阻塞）线程与连接 1:1，十万人连接就要十万个线程，内存与上下文切换直接爆掉；于是走到 NIO（非阻塞 + 多路复用），一个线程用 select/poll/epoll 盯着一堆连接，"谁就绪了才处理谁"。

但 Part01 也埋下一个事实：原生多路复用只是"零件"。真正要做一个能扛高并发、不丢连接、不串数据、还能优雅处理粘包和断线的网络框架，还要解决一堆工程问题（epoll 空转、半包、断连、内存碎片、锁竞争……）。一句话记住 原生 NIO 给你的是"扳手"，Netty 给你的是"整车"。

1. I/O 模型回顾：阻塞/非阻塞、同步/异步、Reactor vs Proactor

1.1 两个独立维度，别混

很多人把"阻塞/非阻塞"和"同步/异步"搞混。它们是两件事：

• 阻塞 vs 非阻塞：说的是"发起 I/O 请求后，线程要不要干等"。阻塞=线程卡在系统调用上；非阻塞=立刻返回（没数据就返回 EAGAIN/0），线程可以去干别的。
• 同步 vs 异步：说的是"数据从内核缓冲区拷到用户缓冲区这件事，谁来负责、何时完成"。同步=I/O 操作本身（含最后的 read 拷贝）由调用方发起并等它完成；异步=调用方只提交请求，内核把数据拷好后再通知你"已完成"。

1.2 Reactor：基于"就绪通知"的事件驱动

Reactor（反应堆）模式的核心是：事件分发器（Dispatcher）+ 多路复用器（Demultiplexer）。它监听"哪些 fd 就绪了"（可读/可写/可连接），一旦就绪就回调对应的事件处理器（Handler）。注意——Reactor 是同步的：它只告诉你"可以读了"，真正的 read() 拷贝还是你线程自己同步做的。

while (true) {
    int n = selector.select();           // 阻塞等"就绪事件"（多路复用）
    for (SelectionKey k : selector.selectedKeys()) {
        if (k.isAcceptable()) accept(k); // 事件分发
        else if (k.isReadable()) read(k);
    }
}

1.3 Proactor：基于"完成通知"的异步

Proactor 走的是真异步 I/O：调用方提交一个异步读请求（含用户缓冲区地址），内核自己把数据从设备读到内核、再拷到用户缓冲区，全部完成后才通知你"读好了，去处理结果"。你全程不碰 read 拷贝。Windows 的 IOCP 是典型 Proactor。

2. Reactor 三种形态：单线程 / 多线程 / 主从多线程

同一个 Reactor 思想，按"连接接收"和"业务处理"是否分线程，演化出三种结构。下面三张图是理解 Netty 线程模型的地基。

3. Java NIO 三件套与那些坑

3.1 三件套：Channel / Buffer / Selector

• Channel（通道）：双向的、面向缓冲区的"连接"。区别于 BIO 的 Stream（单向、字节流），Channel 既能读也能写，且必须配合 Buffer。
• Buffer（缓冲区）：底层是一段连续内存 + 几个指针（position/limit/capacity）。所有读写都经过它——这是"零拷贝"与"少系统调用"的入口。
• Selector（多路复用器）：把多个 Channel 注册到自己身上，一个 select() 就能知道"哪些 Channel 就绪"，实现"一线程管万连接"。Linux 下底层是 epoll。

3.2 原生 NIO 的五大坑

4. Netty 核心架构：Bootstrap 到 Pipeline

Netty 把 §2 的主从 Reactor 和 §3 的零件，封装成一组语义清晰的对象。先建立全局心智模型：

4.1 启动与线程：Bootstrap / EventLoopGroup / EventLoop

• Bootstrap / ServerBootstrap：客户端 / 服务端的"装配器"，把 group、Channel 类型、Handler 串起来 bind()/connect()。
• EventLoopGroup：一组 EventLoop（本质是"一个线程 + 一个 Selector + 一个任务队列"）。Boss 组对应 Main Reactor，Worker 组对应 Sub Reactor。
• EventLoop：单线程串行地处理绑定到它的多个 Channel 的所有 IO 事件与任务。关键设计——无锁串行化：同一 Channel 的所有操作都在同一个 EventLoop 线程里跑，天然不需要加锁。

4.2 责任链：Channel / Pipeline / ChannelHandler / ChannelHandlerContext

• ChannelPipeline：每个 Channel 一条双向链表，装一串 Handler。
• ChannelHandler：分两类——ChannelInboundHandler（响应入站事件：连接、读、注册）与 ChannelOutboundHandler（响应出站请求：写、关闭、flush）。
• ChannelHandlerContext（ctx）：Handler 在链中的"上下文 + 前后指针"。通过 ctx.fireChannelRead() 把事件往后传，用 ctx.write() 触发出站。这把"责任链模式"落到了网络层。

4.3 编解码：ByteToMessageDecoder / MessageToByteEncoder

TCP 是字节流，所以"字节 ↔ 消息对象"的转换必须由应用层完成。Netty 用两个基类把这件事标准化：

• ByteToMessageDecoder：累积收到的 ByteBuf，按帧规则切出完整消息（定长 / 分隔符 / 长度字段，见 §6），输出一个个 POJO 往后传。它内部维护"读不完就攒着"的缓冲，专门解决半包。
• MessageToByteEncoder：把业务 POJO 编码成 ByteBuf 写出，实现"对象 → 字节"。

5. 关键机制：ByteBuf / FastThreadLocal / Future-Promise / 背压水位

5.1 ByteBuf：读写指针分离 + 池化 + 零拷贝

JDK 的 ByteBuffer 只有一个 position 指针，读写要反复 flip()，极易出错。Netty 的 ByteBuf 用两个独立指针：readerIndex（已读/未读分界）和 writerIndex（已写/可写分界），中间是"可读区"，后面是"可写区"，互不干扰。

此外还有 slice()/duplicate()：返回共享同一块内存的新视图（各自维护自己的读写指针），也是"零拷贝"的家族成员——避免为了"取一段"而整体复制。

5.2 FastThreadLocal：比 JDK ThreadLocal 更快

JDK ThreadLocal 底层是"每个线程一张哈希表"，有哈希冲突、弱引用清理、扩容开销。Netty 的 FastThreadLocal 配合 InternalThreadLocalMap：用一个固定下标（index）直接数组寻址，O(1) 且无哈希冲突；只有 Netty 自己的 FastThreadLocalThread 才享受这个数组，普通线程退回普通实现。取舍 用"预分配下标"换"免哈希查找"，代价是下标全局递增、不可回收（轻微内存占用）。

5.3 异步：Future / Promise

Netty 的 ChannelFuture 是"未来会完成的操作的结果"，用 addListener() 回调避免阻塞等待。Promise 是"可写的 Future"——你可以主动 setSuccess()/setFailure() 通知结果。这正是 Reactor 异步世界的"返回值"。一句话记住 在事件驱动里，函数的"返回值"不是 return，而是 Future/Promise 这个"占位信箱"。

5.4 背压与写缓冲水位

当对端收得慢、写出的数据在 Netty 端堆积，内存会被撑爆。Netty 用水位线做背压：

• WRITE_BUFFER_HIGH_WATER_MARK：缓冲超过此值 → channel.isWritable() 变 false，业务应暂停写入。
• WRITE_BUFFER_LOW_WATER_MARK：缓冲降到此值 → isWritable() 重新变 true，恢复写入。

6. 粘包拆包 / 心跳 / 断线重连

6.1 粘包拆包：为什么会发生、怎么解

TCP 是字节流，没有消息边界。发送端两次 write 可能被合并成一个 TCP 包到达（粘包）；一次 write 也可能被拆成两次到达、甚至半个包（拆包/半包）。应用层必须自己界定帧。三种主流定界法：

6.2 心跳：IdleStateHandler

长连接要能发现"对端死了但 TCP 没断"（半开连接）。IdleStateHandler 监测：读空闲（多久没收到）、写空闲（多久没发）、读写空闲。超时触发 userEventTriggered，业务可发心跳包或主动关闭。一句话记住 心跳就是"定时互喊一声，不回应的就当你挂了"。

6.3 断线重连

客户端在 channelInactive 里用 EventLoop.schedule() 延时重试 connect()，配合指数退避（避免雪崩式重连打爆服务端）。服务端一般不用重连逻辑。

7. 对比：原生 NIO vs Netty vs gRPC vs Tomcat

7.1 原生 NIO vs Netty

7.2 Netty vs gRPC 网络层（HTTP/2）

7.3 Netty vs Tomcat NIO Endpoint 线程模型

Tomcat 的 NIO 也走 Reactor + 多路复用，但分工哲学不同：

8. 一句话路线总结