📚 课程目录第4章 Netty线程模型

4、Netty线程模型：EventLoopGroup设计、bossGroup与workerGroup职责、ChannelPipeline机制

Netty 的线程模型，说白了就是它处理网络请求的「流水线工人」怎么分工、怎么协作。我刚开始接触 Netty 时，也被 EventLoop、Group 这些概念绕得头晕。后来在线上压测一个网关项目时，因为线程模型配置不当，导致 CPU 跑满但吞吐量上不去，才真正逼着我把它吃透。

今天咱们就把这块掰开揉碎。核心就三件事：EventLoopGroup 怎么设计、bossGroup 和 workerGroup 各管什么、ChannelPipeline 怎么流转。

4.1 EventLoopGroup：线程池的「高级封装」

EventLoopGroup 本质上是一个无限循环的事件处理器线程池。每个 EventLoop 绑定一个线程，负责处理多个 Channel 的 I/O 事件。

我个人习惯把 EventLoopGroup 理解成「线程管家」——它管理着一组 EventLoop，你只需要告诉它要几个线程，它帮你分配、调度、回收。

核心设计要点：

一个 EventLoop 对应一个线程，线程数通常设置为 2 * CPU 核心数（I/O 密集型）或 CPU 核心数 + 1（混合型）
EventLoop 内部维护了一个 TaskQueue，所有待执行的任务都排队等待
EventLoop 与 Channel 是 多对一 关系：一个 EventLoop 可以服务多个 Channel，但一个 Channel 只绑定一个 EventLoop

为什么一个 Channel 只绑定一个 EventLoop？嗯，这里要注意——避免了锁竞争。所有针对该 Channel 的操作都在同一个线程中串行执行，不需要加锁，性能自然就上去了。

4.2 bossGroup 与 workerGroup：谁该干什么活

Netty 的服务端通常需要两个 EventLoopGroup：bossGroup 和 workerGroup。它们的职责非常清晰：

角色	职责	线程数建议	典型场景
bossGroup	负责接受新连接，把连接注册到 workerGroup	1 个线程（通常够用）	监听端口，处理 OP_ACCEPT 事件
workerGroup	负责处理已建立连接的读写，执行业务逻辑	CPU 核心数 * 2	处理 OP_READ、OP_WRITE 事件

我曾经在一个高并发推送项目中，把 bossGroup 也设成了 8 个线程。结果呢？大部分线程都在空转，因为 accept 事件根本不需要那么多线程来处理。后来改成 1 个线程，资源占用直接降了一半。

我的建议：bossGroup 线程数固定为 1 即可，除非你有多端口监听需求。workerGroup 的线程数根据业务类型调整：

纯 I/O 操作（无阻塞）：CPU 核心数 * 2
混合操作（有少量阻塞）：CPU 核心数 * 4
大量阻塞操作：考虑使用 ChannelHandler 中的线程池，不要阻塞 EventLoop

代码示例：

// 服务端典型配置
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup(Runtime.getRuntime().availableProcessors() * 2);

try {
    ServerBootstrap b = new ServerBootstrap();
    b.group(bossGroup, workerGroup)
     .channel(NioServerSocketChannel.class)
     .childHandler(new ChannelInitializer<SocketChannel>() {
         @Override
         public void initChannel(SocketChannel ch) {
             ch.pipeline().addLast(new MyServerHandler());
         }
     });
    // ... 绑定端口
} finally {
    bossGroup.shutdownGracefully();
    workerGroup.shutdownGracefully();
}

4.3 ChannelPipeline：数据流的「责任链」

ChannelPipeline 是 Netty 最巧妙的设计之一。它把数据的处理过程拆成一个个 ChannelHandler，像流水线一样串起来。

你想想看，一个网络请求进来，可能要经过：
解码 → 鉴权 → 业务处理 → 编码 → 发送响应。

如果把这些逻辑全写在一个类里，代码会变成一坨「意大利面条」。而 Pipeline 让你可以按需组装，每个 Handler 只关心一件事。

Pipeline 的核心机制：

入站（Inbound）：数据从网络读到 Channel，依次经过 ChannelInboundHandler
出站（Outbound）：数据从 Channel 写到网络，依次经过 ChannelOutboundHandler
双向流动：一个 Handler 可以同时处理入站和出站（继承 ChannelDuplexHandler）

我记得有一次排查线上问题，发现某个请求的响应特别慢。抓了线程栈一看，原来是 Pipeline 里加了一个 同步的数据库查询 Handler，直接阻塞了 EventLoop 线程。结果这个 EventLoop 上绑定的其他 Channel 也跟着遭殃——所有连接都卡住了。

避坑指南：千万不要在 EventLoop 线程中执行阻塞操作（如数据库查询、远程调用、文件读写）。如果必须做，请使用 ChannelHandlerContext.executor() 提交到业务线程池，或者使用 addLast(EventExecutorGroup group, ChannelHandler handler) 指定独立的线程组。

Pipeline 的典型结构：

// 自定义 Pipeline 组装
ChannelPipeline p = ch.pipeline();
p.addLast("decoder", new StringDecoder());          // 入站：解码
p.addLast("auth", new AuthHandler());                // 入站：鉴权
p.addLast("encoder", new StringEncoder());           // 出站：编码
p.addLast("business", new BusinessHandler());        // 入站：业务处理

数据流方向：

入站：decoder → auth → business（从前往后）
出站：encoder（从后往前，但只经过出站 Handler）

4.4 整体架构图

下面这张图展示了 Netty 线程模型的核心流转：

4.5 实战调优建议

最后，结合我自己的踩坑经验，给你几条调优建议：

线程数不是越多越好。我曾经把 workerGroup 设成 64 个线程，结果上下文切换开销比实际处理时间还大。后来压测发现，8 线程（4 核机器）反而是最优值。
区分 I/O 线程和业务线程。如果业务逻辑有阻塞操作，一定要用 ChannelHandlerContext.executor() 或者 addLast(EventExecutorGroup, Handler) 隔离出去。
Pipeline 顺序很重要。解码器一定要放在最前面，否则后面的 Handler 拿到的还是字节流。我见过有人把业务 Handler 放在解码器前面，结果数据全是乱码。
监控 EventLoop 的任务队列。如果队列积压严重，说明 EventLoop 处理不过来，要么加线程，要么优化业务逻辑。

一个小技巧：在压测时，可以用 jstack 查看线程状态。如果发现大量线程处于 WAITING 状态，说明线程数过多；如果大量线程处于 RUNNABLE 但 CPU 不高，说明有阻塞操作在偷时间。

Netty 的线程模型，说白了就是「专人专事，流水作业」。bossGroup 只管接客，workerGroup 只管服务，Pipeline 只管把活拆细。理解了这个，你就能根据业务场景灵活调优了。