一、为什么还需要 Netty？原生 NIO 的三道坎

NIO 解决了”一个线程管几万连接”，但把 NIO 用在生产你会立刻撞上三道坎：

1. API 繁琐且易错：Selector、SelectionKey、ByteBuffer 的 flip/clear 稍不留神就数据错位；JDK 还存在著名的 epoll 空轮询 bug（Selector 唤醒却不返回就绪事件，CPU 100%）。
2. 网络语义要自己兜底：断连重连、网络闪断、半包/粘包、读超时、写背压，全部得手写状态机。
3. 线程模型要自己搭：Acceptor 与 IO 线程要不要分离？任务队列怎么排？业务阻塞怎么隔离？每一样都是坑。

Netty 把这三道坎全部封装掉，并且默认就规避了空轮询（用定时重建 Selector 兜底）。它不发明新 I/O，只是把”工程上正确的做法”固化成框架。

谁在用 Netty？Dubbo、RocketMQ、Elasticsearch、gRPC-Java 底层、Spark/Flink 的 RPC 模块、各种网关——它几乎是 Java 高性能网络的”事实标准”。

二、整体架构与线程模型：主从 Reactor

Netty 的核心是 Reactor 模式。它把”等待事件”和”处理事件”拆成两组线程：

1
2

EventLoopGroup boss = new NioEventLoopGroup(1);          // 通常 1 个，accept 很轻
EventLoopGroup worker = new NioEventLoopGroup();         // 默认 2*CPU 核数

对比 NIO 篇的”单 Selector 线程”模型，Netty 的主从 Reactor 相当于把”接收”和”读写”做了关注点分离，Worker 还能横向扩展到多核，这正是它能扛高并发的根因。

三、核心组件总览

ChannelPipeline 是 Netty 最优雅的设计：每个 Channel 都有一条 Pipeline，入站（Inbound）事件从头部向尾部流动，出站（Outbound）事件反向流动。你往 Pipeline 里 addLast 一个个 Handler，数据就依次被加工。

1
2
3

pipeline.addLast(new LengthFieldBasedFrameDecoder(1024, 0, 4)); // 先拆包
pipeline.addLast(new StringDecoder());                          // 再解码
pipeline.addLast(new BizHandler());                             // 最后业务

四、ByteBuf：比 ByteBuffer 聪明在哪

原生 ByteBuffer 只有一个 position 指针，读/写要来回 flip，扩容还得手动 copy。ByteBuf 做了三处改进：

• 读写双指针：readerIndex / writerIndex 分离，读写互不干扰，不用 flip。
• 自动扩容：writeXXX 超出 capacity 时自动倍增扩容，调用方无感。
• 池化与引用计数：PooledByteBufAllocator（默认）复用内存，降低 GC 压力；ReferenceCounted 让你用 retain()/release() 精确控制生命周期。

堆外 DirectByteBuf 能避免一次”堆→堆外”的拷贝，特别适合网络传输；但分配成本高，所以才需要池化。生产环境默认就开启了池化分配器。

五、Pipeline 与 Handler：数据怎么被加工

入站事件由 ChannelInboundHandler 处理（channelActive 连接建立、channelRead 读到数据、exceptionCaught 异常），出站由 ChannelOutboundHandler 处理（write、flush、close）。编解码器是最常用的 Handler：

1
2
3
4
5
6
7

// 服务端把字符串写出去：MessageToByteEncoder 自动把对象编码成 ByteBuf
public class StringEncoder extends MessageToByteEncoder<String> {
    @Override
    protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out) {
        out.writeBytes(msg.getBytes(StandardCharsets.UTF_8));
    }
}

Netty 自带一批”半成品解码器”，专门对付按行、按分隔符、按长度的协议，不用自己写累加逻辑。

六、粘包 / 拆包：TCP 是字节流，必须自己定边界

这是 Netty 里最常踩也最容易讲清的一块。TCP 是面向字节流的，它不保留”消息边界”：发送端两次 write 可能被合并成一个包（粘包），一次 write 也可能被拆成两个 TCP 段到达（拆包）。如果不加处理，接收方读到的就是”半条”或”黏在一起”的数据。

解决思路只有一条：在字节流上定义应用层边界。Netty 给出四种现成方案：

生产上最常用的是长度字段方案，Netty 一个解码器就搞定：

1
2
3
4
5
6
7
8

// 报文 = [长度4字节][body]，长度只算 body
new LengthFieldBasedFrameDecoder(
    1024 * 1024,   // maxFrameLength 最大帧
    0,             // lengthFieldOffset 长度字段偏移
    4,             // lengthFieldLength 长度字段占几字节
    0,             // lengthAdjustment 长度修正
    4              // initialBytesToStrip 解码后跳过头部长度字段
);

七、心跳与空闲检测：IdleStateHandler

长连接最怕”一端挂了，另一端还以为连着”。Netty 内置 IdleStateHandler，按”读空闲 / 写空闲 / 读写空闲”触发事件，你只需在 userEventTriggered 里发心跳或主动断开：

1
2
3
4
5
6
7
8
9
10

pipeline.addLast(new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS)); // 60s 没读到就空闲
pipeline.addLast(new HeartbeatHandler());

// HeartbeatHandler 里
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
    if (evt instanceof IdleStateEvent) {
        ctx.writeAndFlush(new PingMessage()); // 发心跳，超时无响应则 close
    }
}

配合客户端断线重连（捕获 channelInactive 后定时重连），就能撑起稳定的长连接。

八、一个可运行的实战：时间服务器

把上面串起来，一个最小可跑的服务端长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class TimeServer {
    public static void main(String[] args) throws Exception {
        EventLoopGroup boss = new NioEventLoopGroup(1);
        EventLoopGroup worker = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(boss, worker)
             .channel(NioServerSocketChannel.class)
             .childOption(ChannelOption.SO_KEEPALIVE, true)
             .childHandler(new ChannelInitializer<SocketChannel>() {
                 @Override
                 protected void initChannel(SocketChannel ch) {
                     ch.pipeline()
                       .addLast(new LengthFieldBasedFrameDecoder(1024, 0, 4))
                       .addLast(new StringDecoder())
                       .addLast(new TimeServerHandler());
                 }
             });
            ChannelFuture f = b.bind(8080).sync();   // 绑定并阻塞等待
            f.channel().closeFuture().sync();
        } finally {
            boss.shutdownGracefully();
            worker.shutdownGracefully();
        }
    }
}

TimeServerHandler 只需关注业务：在 channelRead 里拿到已经切好的完整消息，处理后 ctx.writeAndFlush(response) 回去。对比原生 NIO 要手写 Selector 循环、ByteBuffer flip、半包累加——Netty 把这些都藏起来了。

九、Netty 与同类选型

一句话：要写自己的协议、自己的网关、自己的中间件，Netty 是首选；如果只是服务间调用，直接用 gRPC/Dubbo（它们底层也是 Netty）更省事。

十、生产避坑清单（10 条）

1. Handler 线程安全：未加 @Sharable 的 Handler 每次 addLast 应是新实例；加了 @Sharable 就要保证无状态/线程安全。
2. ByteBuf 必须释放：非 Pooled/堆外 ByteBuf 忘记 release() 会内存泄漏；用 try-finally 或 ReferenceCountUtil.release() 兜底。
3. 绝不在 EventLoop 里阻塞：DB 查询、同步 HTTP、重计算要丢到独立业务线程池（EventExecutorGroup），否则卡住整条 EventLoop 上的所有连接。
4. Worker 线程数：默认 2*CPU 即可；Acceptor（boss）通常 1 个就够。
5. 开内存泄漏检测：-Dio.netty.leakDetection.level=PARANOID（开发期），上线改 SIMPLE，定位未释放的 ByteBuf。
6. 解码器顺序：FrameDecoder 必须位于业务解码器之前，否则半包/粘包会穿透到业务层。
7. 写操作别忽略结果：writeAndFlush 返回 ChannelFuture，失败要加 addListener 或 exceptionCaught 处理，否则静默丢消息。
8. 背压保护：设置 WRITE_BUFFER_WATER_MARK 高低水位，写缓冲区过高时暂停写入，防止 OOM。
9. 优雅关闭：进程退出务必 shutdownGracefully()，让在途请求跑完再释放资源。
10. 业务线程池隔离：重逻辑用独立 EventExecutorGroup 承接，不要把 IO 线程和业务线程混在一起。