Boss线程组单线程负责连接接入，Worker线程组建议设为CPU核心数，需结合压测调整；每个Channel绑定唯一EventLoop以保证无锁串行处理；业务耗时操作须异步移交但响应写回必须回归原EventLoop；合理利用EventLoop任务队列执行轻量后台任务；线程数需与TCP参数协同优化。
关键在于让 Boss 和 Worker 线程组各司其职、数量合理、绑定稳定，避免线程竞争和上下文切换浪费。
明确 Boss/Worker 分工与线程数配置
BossGroup 只做连接接入（OP_ACCEPT），单线程足够；多开反而引发 Selector 竞争。WorkerGroup 负责所有已连接 Channel 的读写与业务处理，线程数不宜盲目堆叠。默认是 CPU 核心数 × 2，但需结合实际压测调整：若 CPU 使用率长期低于 70% 且 RT 上升，可适当增加；若上下文切换（cs）飙升、CPU sys 时间占比高，则说明线程过多，应减少至接近 CPU 核心数。
- 服务端常见配置：
new NioEventLoopGroup(1)（Boss）、new NioEventLoopGroup(Runtime.getRuntime().availableProcessors())（Worker） - 避免使用无参构造（默认 2×CPU），尤其在容器化部署时，需以
cgroups限制后的可用核数为准
确保 Channel 生命周期内线程绑定不变
Netty 为每个新连接分配一个 EventLoop，并将该 Channel 的全部 I/O 事件（READ/WRITE）、定时任务、用户提交的 execute() 任务都串行调度到同一个线程。这是“无锁化”高性能的核心前提。若在 ChannelHandler 中主动切出线程（如用 CompletableFuture.supplyAsync() 或自建线程池处理业务），就破坏了该保证，可能引发竞态或额外同步开销。
- 业务耗时操作（如 DB 查询、远程调用）必须异步移交，但响应写回仍需回到原 EventLoop：用
channel.eventLoop().execute(() -> channel.writeAndFlush(...)) - 禁止在
channelRead()中直接阻塞等待结果；应配合ChannelPromise或ChannelFuture.addListener()回到原线程完成写操作
合理利用 EventLoop 的任务调度能力
每个 EventLoop 不仅处理 I/O，还维护一个任务队列，支持定时/延时任务（schedule()）和普通异步任务（execute()）。把心跳检测、连接空闲超时、统计上报等轻量后台逻辑交给 EventLoop 执行，比另起线程更省内存与上下文切换资源。
立即学习“Java免费学习笔记（深入）”；
- 例如心跳：在
IdleStateHandler触发userEventTriggered()后，直接调用ctx.writeAndFlush(new PingMsg()).addListener(...)，全程不跨线程 - 避免高频向 EventLoop 提交小任务（如每毫秒
execute()），会拖慢 I/O 处理；可合并或改用时间轮（HashedWheelTimer）
关注线程模型与系统资源的匹配
线程模型不是孤立参数。Worker 线程数过高，若搭配过大的 SO_RCVBUF/SO_SNDBUF（如 4MB），会导致每个连接内存占用激增，触发频繁 GC；若搭配 TCP_NODELAY=false（启用 Nagle），又会在小包场景引入毫秒级延迟。性能调优需协同考虑。
- 建议组合：
TCP_NODELAY=true（禁用 Nagle）、SO_BACKLOG=1024（防连接洪峰丢弃）、SO_RCVBUF/SO_SNDBUF=256KB（平衡吞吐与内存） - 用
pidstat -w -t -p <pid>观察线程级上下文切换，若某 EventLoop 线程 cs 值远高于其他线程，说明该线程负载不均，可能是 Channel 分配策略或业务逻辑不均衡所致
