Netty：EventLoop 线程隔离、业务线程池与背压控制
一、为什么 EventLoop 不能执行耗时任务？
Netty 使用 Reactor 线程模型处理网络事件。一个 EventLoop 通常会负责多个 Channel，并在自己的线程中处理这些 Channel 的 IO 事件和 Pipeline 事件。
例如：
EventLoop-1
├── Channel-A
├── Channel-B
├── Channel-C
└── Channel-D如果 Channel-A 的 Handler 中执行了耗时 5 秒的数据库查询，那么 EventLoop-1 在这段时间内无法及时处理其他任务，Channel-B、C、D 的读写事件也可能被延迟。
public class BusinessHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
// 不推荐：在 EventLoop 线程中执行阻塞数据库操作
queryDatabase();
ctx.fireChannelRead(msg);
}
}核心原则：EventLoop 负责网络 IO 和轻量级事件处理；耗时、阻塞的业务操作应交给独立的业务执行器。
二、使用 DefaultEventExecutorGroup 隔离业务处理
Netty 提供 DefaultEventExecutorGroup，可以让指定 Handler 的事件处理交给独立的业务线程执行。
public class NettyServer {
// 创建业务执行器组，避免每次收到请求都创建线程池
private final DefaultEventExecutorGroup businessGroup =
new DefaultEventExecutorGroup(8);
private void initPipeline(SocketChannel ch) {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(
new LengthFieldBasedFrameDecoder(
1024 * 1024, 4, 4, 0, 0
)
);
pipeline.addLast(new ProtocolDecoder());
// 从这个 Handler 开始，事件由 businessGroup 中的执行器处理
pipeline.addLast(
businessGroup,
"businessHandler",
new BusinessHandler()
);
}
}业务 Handler：
public class BusinessHandler
extends SimpleChannelInboundHandler<DeviceMessage> {
@Override
protected void channelRead0(
ChannelHandlerContext ctx,
DeviceMessage msg) {
// 这里执行耗时业务，不占用原来的 IO EventLoop 线程
queryDatabase(msg);
ctx.writeAndFlush("处理完成");
}
}需要理解：
DefaultEventExecutorGroup是 Netty 提供的执行器组，不是 Java 线程池 API 本身。pipeline.addLast(group, handler)会将指定 Handler 的事件处理分配给该执行器组中的执行器。不要在每条消息到来时创建新的线程池，应复用执行器组。
业务线程池也有容量限制。线程数不足、任务队列堆积或数据库连接池耗尽，同样会造成延迟。
不要把所有 Handler 都放进业务线程池。协议解码、轻量级状态处理通常可以留在 EventLoop。
如果 Handler 实例会被多个 Channel 或线程共享，必须保证线程安全；只有满足线程安全条件时才能使用
@Sharable。如果业务要求严格的消息顺序，应检查线程池分配和异步任务设计，不能假设任意业务线程池都会替你保证所有业务操作顺序。
对于特别耗时的阻塞业务，可以使用独立、有界队列的业务线程池，并配置合理的拒绝策略，避免任务无限堆积。
三、写缓冲区水位线与背压
假设服务端持续向客户端发送数据，但客户端网络较慢，接收速度远低于服务端发送速度。尚未写入底层网络的待发送数据可能在服务端不断堆积。
Netty 提供 WriteBufferWaterMark，用于定义 Channel 写缓冲区的低水位和高水位。
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.childOption(
ChannelOption.WRITE_BUFFER_WATER_MARK,
new WriteBufferWaterMark(
32 * 1024, // 低水位：32 KB
64 * 1024 // 高水位：64 KB
)
);水位线的含义：
监听可写状态变化：
public class BusinessHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelWritabilityChanged(
ChannelHandlerContext ctx) throws Exception {
if (!ctx.channel().isWritable()) {
// 写缓冲区压力较大：暂停或减缓向该 Channel 生产数据
System.out.println("Channel 暂时不可写");
} else {
// 缓冲区压力缓解：可以恢复发送
System.out.println("Channel 恢复可写");
}
ctx.fireChannelWritabilityChanged();
}
}注意：
isWritable() == false不代表 TCP 连接断开。水位线不是严格的内存上限，也不会自动暂停业务生产者。
应用程序需要根据可写状态暂停、限速或排队发送，并为业务队列设置上限。
不能无限制地把消息放进另一个无界队列，否则只是把压力从 Netty 写缓冲区转移到了业务队列。
四、常见问题与答案
1. 为什么不能在 EventLoop 中执行耗时 SQL？
因为多个 Channel 可能共用一个 EventLoop。阻塞操作会占用 EventLoop 线程，延迟其他 Channel 的事件处理。
2. DefaultEventExecutorGroup 是什么？
Netty 提供的事件执行器组，可以将指定 Handler 的事件处理交给独立执行器运行，避免耗时业务阻塞 IO EventLoop。
3. 是否所有 Handler 都应该放进业务线程池？
不是。解码、轻量级校验和简单状态处理通常可以留在 EventLoop。应只将确实耗时或阻塞的业务处理隔离出去。
4. Channel.isWritable() 返回 false 是不是断线？
不是。它表示 Channel 的待发送数据达到高水位，当前存在写缓冲区压力。
5. 设置水位线后，Netty 会自动停止业务发送吗？
不会。水位线改变 Channel 的可写状态并触发可写状态事件，应用程序仍需主动控制消息生产和发送。
五、重点总结
一个 EventLoop 通常负责多个 Channel，不能在其中执行长时间阻塞任务。
DefaultEventExecutorGroup可以隔离耗时业务 Handler 与 IO EventLoop。业务线程池也要控制线程数、队列容量和拒绝策略。
不要为了隔离业务而把所有 Handler 都交给业务线程池。
WriteBufferWaterMark用于监控和控制待发送数据的水位。isWritable() == false表示写缓冲区压力较大，不代表连接断开。背压需要应用程序配合暂停、限速或有界排队，不能只配置水位线。