Netty WebSocket服务端高并发落地的关键在于线程模型、内存管理与连接生命周期控制三者协同优化：BossGroup应固定为1线程，WorkerGroup设为min(8, CPU核心数×2)，需显式配置SO_KEEPALIVE、合理设置WebSocketServerProtocolHandler参数并严格管控ByteBuf引用计数与Channel状态清理。
直接说结论：Netty 实现 WebSocket 服务端不是“写个 WebSocketServerProtocolHandler 就完事”，真正卡住高并发落地的，是线程模型配置、内存管理策略和连接生命周期控制这三处。用错默认参数，5000 连接就可能触发频繁 GC 或 ChannelInactive 异常。
Netty WebSocket 启动时 BossGroup 和 WorkerGroup 怎么配
常见错误是把 BossGroup 和 WorkerGroup 都设成相同大小，甚至都用 new NioEventLoopGroup() 不传参——这会导致 CPU 核心数 ×2 的线程无差别抢夺连接 Accept 和 I/O 事件，实际压测中会出现连接建立延迟突增、握手超时（WebSocketHandshakeException）。
正确做法：
-
BossGroup固定为 1 个线程：它只做 accept，多线程反而引入锁竞争 -
WorkerGroup设为Math.min(8, Runtime.getRuntime().availableProcessors() * 2)：避免线程过多导致上下文切换开销，也防止过少无法吞吐大量连接读写 - 必须显式调用
.childOption(ChannelOption.SO_KEEPALIVE, true)：否则空闲连接在 NAT 网关或负载均衡器后容易被静默断开
WebSocketServerProtocolHandler 的关键参数怎么设
这个 Handler 是握手和帧解析的核心，但它的构造函数有 5 个重载，最易踩坑的是第三个和第四个参数：checkStartsWith 和 allowExtensions。默认值会拒绝带子协议（subprotocol）的客户端请求，比如前端用 new WebSocket(url, ['chat-v2']) 就直接 400。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
实操建议：
- 显式传入
new WebSocketServerProtocolHandler("/ws", "chat-v1,chat-v2", true, 65536, false)：第三个参数true表示允许子协议，第四个参数限制单帧最大 64KB，防内存溢出 - 务必在 Pipeline 中把它放在
HttpObjectAggregator之后、自定义业务 Handler 之前；顺序错会导致HttpRequest被丢弃或TextWebSocketFrame解析失败 - 不要依赖它的默认心跳机制——它只响应 ping 帧，不主动发；真实场景需自己加
IdleStateHandler+ 定时发送PingWebSocketFrame
为什么连接数上万后 ChannelInactive 频发
这不是 Netty 本身的问题，而是业务层没接管好连接状态。Netty 的 Channel 关闭后，如果业务代码还持有其引用（比如存进 ConcurrentHashMap<channelid channel></channelid> 却没及时 remove），下次尝试 writeAndFlush 就抛 ChannelException: channel inactive，日志里满屏都是这个。
关键动作：
- 在自定义
SimpleChannelInboundHandler的handlerRemoved方法里，必须同步清理所有该Channel的缓存（Redis 在线用户表、本地 Map、连接计数器） - 禁止在
channelRead0中做耗时操作（如 DB 查询、HTTP 调用），否则阻塞 EventLoop，导致其他连接的心跳超时被踢 - 用
ctx.executor().submit(() -> { /* 耗时逻辑 */ })把重操作扔出 EventLoop 线程池，但注意别用Executors.newCachedThreadPool()——它无限创建线程，OOM 风险极高
最常被忽略的一点：Netty 的 ByteBuf 是引用计数对象。收到 TextWebSocketFrame 后，如果不调用 retain() 就存起来异步处理，后续 release() 可能已被自动触发，再读就是非法内存访问。这个 bug 在高并发下极难复现，但一旦出现就是偶发性崩溃。
