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); IteratorSelectionKey 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 唤醒 bugCPU 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/O0按核数 ServerBootstrap b new ServerBootstrap(); b.group(boss, worker) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { 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上。这就是经典的主从 ReactorReactor 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 空转 bugJDK 原生有需 workaroundNetty 已规避且 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_NODELAYtrue要开。默认 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 上发生的为什么这样设计你在自研网络层上踩过哪些坑评论区聊聊。