自己用 NIO 写服务端那天，半包把一条连接挂了 40 分钟：Reactor 模型到底帮你挡了什么
title: 自己用 NIO 写服务端那天，半包把一条连接挂了 40 分钟：Reactor 模型到底帮你挡了什么
tags: [Java, Netty, NIO, Reactor, 网络编程]
category: Java 后端
"我们想自己写个轻量 RPC"
前年我们做一个内部中间件，定位是"公司内部服务之间通信用的轻量 RPC"，设计目标里有一条："不依赖 Netty，自己基于 JDK NIO 实现，减少依赖、可控"。
这个决定现在回头看是整件事最大的坑，但当时理由很充分：Netty 4.1 依赖 20 多个类、版本升级要回归、出了底层问题还得读 Netty 源码。我们觉得"NIO 不就是 Selector + Channel 嘛，几百行就能写一个"。
写出来之后压测也过了，QPS 2 万没掉链子。上线到生产，前两天下游反馈偶尔有请求"发了没响应、也不报错"，频率很低，一天一两次，重启客户端就恢复，一直没认真查。
真正出大事是某次大促，下游把连接数从 200 提到 2000，那个"偶尔无响应"变成了"每分钟十几条"。一条连接挂住之后，客户端线程池很快被占满，从一条连接拖塌一个调用方，再传染给其他调用方。故障持续 40 分钟，影响面比我们想象的大得多。
那段"看起来没问题"的 NIO 读处理
核心就是这个读事件处理。单机单 Selector，一个线程轮询：
public class NioServer { private final Selector selector; private final ByteBuffer readBuf = ByteBuffer.allocate(1024); // 复用缓冲区 void loop() throws IOException { while (true) { selector.select(1000); Iterator<SelectionKey> it = selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key = it.next(); it.remove(); if (key.isAcceptable()) { accept(key); } else if (key.isReadable()) { handleRead(key); // 出问题的地方 } } } } void handleRead(SelectionKey key) throws IOException { SocketChannel ch = (SocketChannel) key.channel(); readBuf.clear(); int n = ch.read(readBuf); // 一次 read if (n == -1) { ch.close(); key.cancel(); return; } readBuf.flip(); // 假设每帧固定 32 字节，一次 read 一定读满一帧 while (readBuf.remaining() >= 32) { byte[] frame = new byte[32]; readBuf.get(frame); dispatch(frame); // 交给业务线程处理 } } }这段代码至少有三个问题，但最致命的是第 25 行的假设："一次read一定读满一帧（32 字节）"。
TCP 是字节流，没有消息边界。一个 32 字节的帧，内核可能分两次read给你：第一次 20 字节，第二次 12 字节。这叫半包（拆包）。反过来，一次read也可能带回两条帧，叫粘包。
半包发生时，第一次read只拿到 20 字节，readBuf.remaining()是 20，小于 32，那个while循环一次都不进，这 20 字节被readBuf.clear()在下一次读事件里直接覆盖丢弃了。于是这条连接上后续的帧永远对不齐，解码出来的全是错位字节，业务层按协议校验失败，但不关连接、不抛异常——连接就僵在那，客户端一直等到超时。
为什么平时不出问题、大促就爆？因为半包的概率和网络路径上是否经过缓冲/代理、是否启用 Nagle 算法、发送方是否一次性写强相关。大促时连接数飙升、跨机房流量增多、中间经过更多 LB 和代理，半包出现频率从"万分之一"涨到"百分之一"，故障就从偶发变成常态。
JDK NIO 的坑，远不止半包
把 NIO 服务端写对，要处理的事情比想象中多。我把我们踩过的和业内公认的坑列一下：
| 坑 | 现象 | 不处理的后果 |
|---|---|---|
| 半包/粘包 | 一次 read 读不全一帧 | 解码错位、连接僵死 |
ByteBuffer复用未清理 | 残留上次的字节 | 偶发性脏数据 |
Selector.select()空转（Linux epoll 唤醒 bug） | CPU 100%，selectedKeys 为空 | 服务假死，JDK 早期版本特有（NIO bug 6403933） |
| 业务处理阻塞在 I/O 线程 | 一个慢请求拖垮所有连接 | 整服务吞吐塌方 |
未处理OP_WRITE | 发送缓冲区满时write返回 0 | 消息丢失或无限循环重试 |
OP_ACCEPT与OP_READ共用一个 Selector 线程 | 建连风暴时读事件被饿死 | 已建连接无响应 |
光半包这一项，正确做法是每个连接维护一个累积缓冲区（readBuf不能全局复用，要 per-Channel），把每次读到的字节 append 进去，循环尝试从累积区里切出一个完整帧，切不出来的部分保留到下次。写出来大概是这个意思：
class Connection { final ByteBuffer accumulator = ByteBuffer.allocate(8192); // per-Channel final SocketChannel ch; void onReadable() throws IOException { ByteBuffer tmp = ByteBuffer.allocate(1024); int n = ch.read(tmp); if (n == -1) { ch.close(); return; } // 把新读到的字节合并进累积区 tmp.flip(); ByteBuffer merged = ByteBuffer.allocate(accumulator.position() + tmp.remaining()); merged.put(accumulator.flip()); merged.put(tmp); merged.flip(); // 循环切帧，切不出的保留 while (merged.remaining() >= FRAME_LEN) { byte[] frame = new byte[FRAME_LEN]; merged.get(frame); dispatch(frame); } accumulator.clear(); accumulator.put(merged); // 剩余字节留给下次 } }这个版本才勉强能用了——但它还差很多：缓冲区要有上限防止恶意客户端打爆内存、merge每次 new 一个大数组性能很差（应该用CompositeByteBuf那种零拷贝思路）、还要处理OP_WRITE的背压。写着写着就发现：我们其实在重新发明 Netty 的ByteToMessageDecoder。
Netty 的 Reactor 主从多线程，到底帮你做了什么
既然在重造轮子，不如先看 Netty 怎么做的。Netty 服务端标准启动代码：
public class NettyServer { public void start() throws Exception { EventLoopGroup boss = new NioEventLoopGroup(1); // 主 Reactor：只负责 accept EventLoopGroup worker = new NioEventLoopGroup(0); // 从 Reactor：处理 I/O，0=按核数 ServerBootstrap b = new ServerBootstrap(); b.group(boss, worker) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new LengthFieldBasedFrameDecoder(1024, 0, 4)) // 自动解决半包/粘包 .addLast(new MyBusinessHandler()); } }) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true); // 关掉 Nagle，降低延迟 b.bind(8080).sync(); } }对比我们的手写版本，差异一目了然。核心在三层：
第一层：主从 Reactor 分工。boss这个EventLoopGroup只干一件事——监听端口、accept新连接。每accept一个连接，就把对应的SocketChannel注册到worker里的某一个EventLoop上。这就是经典的主从 Reactor（Reactor Master-Worker）模式：boss是主 Reactor，应对"建连"这个相对低频但集中的事件；worker是从 Reactor 数组，每个EventLoop用一个线程跑一个死循环select + 处理，负责成百上千条已建连接的读写。
为什么不是"一个 Selector 一个线程管所有"？因为accept风暴和read风暴会互相挤占。建连密集时，如果accept和read抢同一个 Selector 线程，已经建立好的连接会在建连期间"饿着"。拆成两个组，建连和读写彻底解耦。
第二层：每个 Channel 绑定唯一 EventLoop。Netty 保证一条连接的生命周期内，它的所有 I/O 事件都由同一个EventLoop线程处理。这意味着你的ChannelHandler里不需要加锁——同一个 channel 的channelRead永远不会并发执行。这是 Netty 性能高、且写业务代码简单的关键。我们自己手写的 NIO，如果不小心让多个 Selector 线程碰同一个 Channel，就得自己加锁，一加锁就容易死锁。
第三层：LengthFieldBasedFrameDecoder替你解决半包。看上面第 13 行，一行的代价，就把我们手写得 40 行还一堆坑的"累积 + 切帧"逻辑接管了。它按"长度字段 + 内容"的格式自动攒够一帧再往下传，半包粘包你完全不用管。类似的还有DelimiterBasedFrameDecoder（按分隔符）、LineBasedFrameDecoder（按行），覆盖了绝大多数自定义协议。
对比表：
| 能力 | 手写 NIO（我们） | Netty |
|---|---|---|
| 半包/粘包 | 自己写累积 + 切帧，易错 | LengthFieldBasedFrameDecoder一行解决 |
| 主从 Reactor | 需自己设计 boss/worker 分组 | group(boss, worker)原生支持 |
| 每连接单线程模型 | 需自己约束 | 框架保证，Handler 无锁 |
| 缓冲区零拷贝拼装 | 自己 new 大数组 | CompositeByteBuf/ByteBuf池化 |
| epoll 空转 bug | JDK 原生有，需 workaround | Netty 已规避（且 Linux 上可用EpollEventLoopGroup） |
| 背压/OP_WRITE | 自己处理 | Channel.write返回ChannelFuture，满了自动挂起 |
| 内存池 | 无 | PooledByteBufAllocator，默认开启 |
我们为什么一开始查错方向
故障定性花了 40 分钟，根因定位又花了 1 小时，中间的弯路值得记：
第一步查的是客户端超时配置。因为现象是"客户端等不到响应"。我们把客户端超时从 3 秒调到 10 秒，没用——因为连接本身就是僵死的，调到 1 小时也只会让客户端等更久。这个方向浪费了 15 分钟。
第二步查的是 GC。半包导致连接挂死，客户端线程池被占满，我们以为是线程暴涨引发 GC 压力。看了 GC 日志正常，又看线程数确实在涨，但线程涨是结果不是原因。又绕了 20 分钟。
真正定位靠的是抓一条僵死连接的字节流。我们临时在handleRead里加了日志，打印每次read的实际字节数，发现那些僵死的连接有个共同特征：最后一次read的返回值是 20、29、17 这种"不到 32 的整数"，之后就再也没有isReadable事件了。这说明帧被拆了，而且残留的那 20 字节正好被下一次clear()覆盖——正是半包 + 缓冲区复用的双重坑叠在一起。
经验：处理 TCP 时，永远假设一次 read 拿不全一帧、也永远假设一次 read 会多拿几帧。这一条应该刻在每个写网络程序的人脑子里。凡是ByteBuffer全局复用 +remaining() >= 帧长直接切帧的写法，都有半包隐患。
选型上的取舍
| 方案 | 可控性 | 开发成本 | 性能 | 适合场景 |
|---|---|---|---|---|
| 手写 NIO | 最高 | 极高（要自己处理 6+ 类坑） | 理论最高（无框架开销） | 学习、极特殊定制协议 |
| Netty | 中（暴露了足够 hooks） | 低（解码器/引导类齐全） | 接近手写 | 99% 的网络服务端 |
| gRPC / 现成 RPC 框架 | 低（协议定了） | 极低 | 良好 | 内部服务通信直接用 |
我们最后的选择是：放弃了自研，迁移到 Netty。理由讲给当时拍板的那位同学听，他认同了三点：
性能差距不值得。Netty 这些年把
ByteBuf池化、零拷贝、epoll 空转规避都做透了，手写 NIO 在吞吐上很难超过它，反而大概率因为某个边角 bug 比它慢。我们压测 2 万 QPS 的"成绩"，Netty 用默认配置就能轻松达到。风险不对称。自研 NIO 出 bug 的概率是"必然"，只是早晚；而 Netty 的 bug 是"小概率且社区已修"。拿"少几个依赖"去换"连接随机僵死"，这笔账不划算。
招人成本。能写好 NIO 的人少，能维护好 Netty 的人多。自研意味着这坨代码只有写它的两个人看得懂，团队其他人改不动。
迁移后的读取处理，业务 Handler 里拿到的已经是完整的一帧：
public class MyBusinessHandler extends ChannelInboundHandlerAdapter { @Override public void channelRead(ChannelHandlerContext ctx, Object msg) { ByteBuf frame = (ByteBuf) msg; // LengthFieldBasedFrameDecoder 保证这一定是一整帧 try { byte[] data = new byte[frame.readableBytes()]; frame.readBytes(data); dispatch(data); } finally { frame.release(); // ByteBuf 池化，必须 release，否则内存泄漏 } } }复盘数字
| 指标 | 自研 NIO 版本 | 迁移 Netty 后 |
|---|---|---|
| 大促期间"无响应"连接数 | 每分钟 12-18 条 | 0 |
| 故障时长 | 40 分钟（需人工介入重启） | — |
| 单机 QPS（同硬件） | 2.0 万（压测峰值） | 4.3 万（默认配置，未调优） |
| 单连接内存占用上限 | 无（accumulator 无上限，有 OOM 风险） | 受RecvByteBufAllocator自适应控制 |
| 协议解码相关代码行数 | ~120 行（含半包处理，仍不健壮） | 1 行（LengthFieldBasedFrameDecoder） |
| 团队可维护人数 | 2（作者本人） | 全体后端（Netty 通用技能） |
QPS 从 2 万到 4.3 万这一段提升，主要不是 Netty 比我们快，而是我们自研版本在半包时会把字节覆盖丢弃、连接僵死、客户端重连风暴反压服务端——这些隐性损耗在迁移后全部消失。
我的几点看法
不要用 NIO 练手代码扛生产流量。学 NIO 应该写、应该读源码理解 Reactor，但生产上用它直接承载业务，等于把半个 Netty 的复杂度自己扛一遍，还扛得没人家好。我见过太多"为了轻量"最后写出一堆ByteBuffer坑的团队。
半包/粘包不是协议设计缺陷，是 TCP 的本质。凡是说"我们的协议用特殊分隔符所以不会有粘包"的，基本都没真正理解：分隔符本身也可能被拆在两次read里，或者两个分隔符挤在一次read里。长度字段（length-prefixed）是最省心的解码方式，没有之一。
boss线程数设 1 就够。很多人把boss也设成跟核数一样多，其实accept一个连接是微秒级操作，一个EventLoop足够应对绝大多数场景的建连速率。设多了反而增加线程切换。
TCP_NODELAY=true要开。默认 Nagle 算法会把小包攒一攒再发，在 RPC 这种"一发一收"的场景下会平白增加几十毫秒延迟。Netty 默认帮你开，自己写 NIO 很容易忘。
不适合用 Netty 的场景：你要的是极致的、特定协议下的微秒级控制，比如某些高频交易网关，这时候直接基于 JNI 调epoll/io_uring、甚至用 Rust 写才是正道，Netty 的 JVM 层和对象分配开销反而成了瓶颈。除此之外，Netty 是默认答案。
思考题
- 如果一条连接的
channelRead里做了 200ms 的 DB 查询（未切到业务线程），会发生什么？Netty 怎么避免这个问题？ LengthFieldBasedFrameDecoder里lengthFieldOffset、lengthFieldLength、lengthAdjustment三个参数分别解决什么？假设帧格式是[4字节魔数][4字节长度][内容]，该怎么填？- 主从 Reactor 里，
boss只accept不read。那"新连接第一次的读"是在哪个 EventLoop 上发生的？为什么这样设计？
你在自研网络层上踩过哪些坑？评论区聊聊。