bossGroup 通常只配1个线程，因其仅负责accept新连接，单线程在epoll ET模式下足以高效处理，多线程反而引发锁竞争、上下文切换及连接丢失风险。
为什么 bossGroup 通常只配 1 个线程？
因为它的唯一职责是 accept 新连接，不处理任何读写或业务逻辑。Linux 的 epoll 在边缘触发（ET）模式下，一次 accept 调用可能返回多个就绪连接，单线程完全能扛住；加更多线程反而引入无谓的锁竞争和上下文切换。
常见错误是照搬 workerGroup 配法，设成 Runtime.getRuntime().availableProcessors() * 2，结果 bossGroup 线程空转、资源浪费，还可能因多线程争抢 ServerSocketChannel.accept() 导致连接丢失。
-
bossGroup必须用NioEventLoopGroup(1)，不能省略参数（默认是 CPU 核数，危险） - 若部署在容器中（如 Kubernetes），
Runtime.getRuntime().availableProcessors()可能返回宿主机核数，需通过cgroup限制或显式配置 - 极少数场景（如单机承载超 500 万连接且 accept 压力异常高）才考虑用 2 个线程，但需配合
SO_REUSEPORT内核支持
workerGroup 线程数不是越多越好
每个 EventLoop 绑定一个线程，负责轮询其管理的所有 Channel 的 I/O 事件 + 执行任务队列。线程数超过 CPU 核心数太多，会导致频繁上下文切换，CPU 时间片被内核调度器吃掉，实际吞吐反而下降。
实测数据表明：在 8 核机器上，workerGroup 设为 12～16 线程时 WebSocket 连接密度最高；设为 32 时，P99 延迟跳升 3 倍，GC 频率增加 40%。
- 推荐公式：
Math.min(Runtime.getRuntime().availableProcessors() * 2, 16)，上限封顶 16，避免盲目扩容 - 如果业务 Handler 中有阻塞调用（如同步 DB 查询、HTTP 调用），必须剥离到独立线程池，否则会卡死整个
EventLoop - 可通过
EventLoopGroup.next()观察各线程负载是否均衡；严重不均说明 Channel 分配策略或心跳逻辑有偏差
WebSocket 连接内存开销远不止一个 Channel
每个长连接在 JVM 中至少持有：Channel、ChannelPipeline、ChannelHandlerContext、ByteBuf 读写缓冲区、业务 Session 对象、心跳定时任务引用。粗略估算，一个空闲连接常驻内存约 80KB～150KB。
100 万连接 ≈ 80GB～150GB 堆外+堆内内存。JVM 堆设太大（如 >32GB）会触发 G1 的并发标记卡顿，堆太小又频繁 Young GC —— 这是百万连接最隐蔽的崩盘点。
- 必须启用
PooledByteBufAllocator，禁用unpooled，否则每条消息都 new 堆外内存，GC 压力翻倍 - 关闭
ChannelOption.SO_RCVBUF和SO_SNDBUF的自动调整（设为固定值如 64KB），防止内核缓冲区无节制膨胀 - 心跳包尽量复用同一块
ByteBuf，避免每次构造新对象；业务 Session 尽量精简字段，避免引用大对象
ChannelOption 关键配置不能只抄模板
像 TCP_NODELAY、SO_KEEPALIVE 这些选项，看似通用，但在百万连接场景下，微小差异会放大成雪崩效应。
-
TCP_NODELAY = true：必须开启，禁用 Nagle 算法，避免小包合并延迟，对心跳和实时消息至关重要 -
SO_KEEPALIVE = false：建议关闭，由应用层心跳（如 WebSocket ping/pong）接管保活，内核 keepalive 间隔不可控且易误杀活跃连接 -
SO_BACKLOG = 1024：够用，过高可能耗尽内核连接队列，反而导致 SYN 包被丢弃；配合系统参数net.core.somaxconn一起调 -
WRITE_BUFFER_WATER_MARK必须显式设置（如new WriteBufferWaterMark(32 * 1024, 64 * 1024)），否则写积压时可能 OOM 或触发强制断连
真正难的不是知道该配什么，而是当连接数从 10 万涨到 80 万时，哪几个参数开始成为瓶颈——这需要结合 Netty 的 ChannelMetrics、jstat 和 perf 工具交叉验证，而不是靠经验拍脑袋。
