Netty 的线程模型和 HTTP 交互中的线程流转过程是什么？

核心回答

以 Netty 4.1 的常见 NIO 服务端配置为例，boss EventLoopGroup 处理监听 Channel 的连接接入，接受新连接后将其注册给 worker EventLoop；worker 负责该连接的 I/O 事件和任务。一个 EventLoop 通常服务多个 Channel，连接的 I/O 不需要每次临时创建一个线程。

没有额外执行器时，连接 Pipeline 中的普通处理器通常运行在所属 I/O EventLoop 上；若为业务处理器配置执行器或主动提交异步任务，就会发生线程切换。因此不能笼统说一次请求的所有代码永远在一个线程执行。

一次 HTTP 请求怎样流转

1. 客户端连接：客户端 Bootstrap 发起异步连接，其 EventLoop 处理连接完成事件；服务端 boss 所在监听 Channel 收到 accept 就绪事件并接受连接。
2. 注册连接：新建的 SocketChannel 被分配并注册到 worker 的 EventLoop，初始化对应 Pipeline。boss 继续处理后续接入，不负责每次 HTTP 请求的业务计算。
3. 接收和解码：worker 监听可读事件，读取字节，由 HTTP 解码器按协议解析为请求头、内容等消息。需要完整消息时可按上限配置聚合器，不能假设一次 TCP read 恰好得到一个完整 HTTP 请求。
4. 业务处理：入站事件按 Pipeline 顺序传播到业务处理器。简单逻辑可以直接处理；慢数据库、文件或阻塞调用应交给有界业务执行器，避免阻塞同 EventLoop 上的其他连接。
5. 响应写出：业务生成响应，通过出站处理器编码并异步提交写入/刷新。最终 Socket I/O 由对应 EventLoop 协调；调用 writeAndFlush 返回不代表对端应用已经处理成功。
6. 客户端接收：客户端自身 EventLoop 读取并解码响应，触发客户端处理器或完成后续结果通知。客户端与服务端的线程组是各自独立的。

Pipeline 与线程安全

入站和出站传播方向不同，还受从 Channel 还是某个 HandlerContext 发起操作影响。为某个处理器指定 EventExecutorGroup，可以把它的回调移出 I/O 线程；此时要检查消息顺序、共享状态和结果返回顺序。

同 Channel 的默认事件顺序有助于减少并发控制，但共享到多个 Channel 的 Handler、业务线程池中的数据和跨连接状态，仍需保证线程安全。引用计数消息跨异步边界时，也要明确所有权与释放，避免过早释放或泄漏。

常见追问

worker 是业务线程池吗？ 默认它首先是 I/O 事件循环组。耗时任务塞进 worker 会阻塞网络事件，并非自动获得一个隔离的业务线程池。

boss 和 worker 必须固定多少线程？ 数量取决于传输实现、配置和负载，不能把示例或历史默认值当作普遍最佳值。

参考资料