我们是如何将Netty网关的线程模型压榨到极限的

做网关三年，最折磨人的不是功能迭代，而是“CPU看起来还有余量，请求却已经开始排队”。我们最初用 Netty 的时候，觉得高并发已经稳了，可每次压测一上量，P99 延迟就像坐了火箭。抓了 thread dump 才发现：我们只是拿 Netty 当了一个高性能壳，真正的业务逻辑还是大包大揽地跑在 EventLoop 上——线程模型从第一天起就被我们用坏了。

先让IO线程做回IO

很多人对 Netty 有个误解：认为 Netty 的线程模型是“多线程并发处理请求”。实际上，每个 Channel 在生命周期内只绑定一个固定的 EventLoop，所有 IO 事件都由这一个线程串行处理。这意味着，只要你在 channelRead 里做了一次耗时操作，比如 RPC 调用或者 DB 查询，这个线程上所有的连接都得排队等它回来。

我们第一刀，就是把所有“非 IO 逻辑”从 EventLoop 上剥出去。ChannelHandler 里只保留协议解码、拆包粘