线程池是Netty自定义协议中业务解耦的关键枢纽，必须分离I/O线程与业务线程以避免阻塞EventLoop；推荐使用DefaultEventExecutorGroup配置业务线程池，并将业务逻辑封装为无状态POJO，注意跨线程数据传递时拷贝必要字段、安全写出。
在基于 Netty 的自定义协议网络编程中，线程池不是“可选配件”，而是业务解耦的关键枢纽——它把协议解析、连接管理这些轻量 I/O 操作，和查库、调服务、复杂计算等耗时业务逻辑彻底隔开，避免拖垮整个网络吞吐能力。
为什么必须分离 I/O 线程与业务线程
Netty 的 EventLoop（如 NioEventLoop）默认单线程串行处理一个 Channel 的所有事件。如果在 handler 里直接执行数据库查询或远程调用，这个线程就会卡住，导致：
- 同一 Channel 后续读写被阻塞，出现延迟毛刺甚至超时
- 其他 Channel 的事件也被排队等待，整体并发能力断崖式下降
- 心跳检测、空闲检测等关键机制失灵，连接异常断开风险上升
如何配置与绑定业务线程池
推荐使用 DefaultEventExecutorGroup 而非普通 ExecutorService，因为它与 Netty 的 EventLoop 生命周期对齐，支持优雅关闭、任务排队、线程复用等特性：
- 初始化：
EventExecutorGroup businessGroup = new DefaultEventExecutorGroup(8);（数字按 CPU 核心数 × 2 估算） - 注册到 pipeline：
pipeline.addLast(businessGroup, new CustomProtocolHandler()); - Netty 自动将 handler 中的
channelRead等方法调度到该线程池执行，无需手动 submit
业务逻辑封装成 Runnable 或 Supplier 更利于解耦
把具体业务操作抽离为独立类，不依赖 ChannelHandlerContext 或 ByteBuf，能带来三重好处：
立即学习“Java免费学习笔记（深入）”；
- 可测试性强：脱离 Netty 环境，直接 new + run 即可验证输入输出与异常路径
- 策略可插拔：调试时用同步执行；生产用线程池；资源紧张时换为 ScheduledThreadPool 控制并发或延时重试
- 状态安全：构造时传入请求参数、响应上下文、回调对象，内部不维护字段，天然无状态、线程安全
注意跨线程的数据传递边界
从 EventLoop 线程切换到业务线程后，不能继续操作 Netty 的原生对象（如 ByteBuf、ChannelPromise），否则会触发引用计数异常或内存泄漏：
- 应在 I/O 线程完成解码后，将业务所需数据（如消息 ID、用户 ID、JSON 字符串）拷贝为 POJO 或 Immutable 对象再传入
- 返回结果时，由业务线程通过
ctx.executor().execute(() -> ctx.writeAndFlush(...))切回 EventLoop 安全写出 - 避免在 Runnable 中持有 ChannelHandlerContext 引用，防止隐式线程绑定
