Netty采用异步非阻塞I/O与Reactor线程模型，仅用少量NioEventLoop线程（通常CPU核数×2）轮询管理海量连接，避免BIO每连接一线程导致的线程栈耗尽问题。
这个问题核心在于线程模型设计不当——用传统 BIO 每连接一线程的方式处理 WebSocket，会快速耗尽 JVM 的线程栈内存（-Xss），尤其在 10 万级连接时，即使堆内存充足，也会触发 java.lang.OutOfMemoryError: unable to create new native thread。
改用异步非阻塞 I/O 模型
彻底放弃“每个连接绑定一个线程”的思路，转向事件驱动架构：
- Spring WebSocket 默认底层依赖 Tomcat 或 Jetty，它们在高并发下仍可能退化为线程池+阻塞读写；应显式切换到 Netty 作为 WebSocket 服务容器（如通过
netty-websocket或自定义ChannelHandler） - Netty 使用少量
NioEventLoopGroup线程（通常 CPU 核数 × 2）轮询成千上万个连接的就绪事件，线程栈开销固定，不随连接数增长 - 若必须用 Spring Boot，可配置嵌入式容器为 Reactor Netty：
spring.main.web-application-type=reactive+spring-boot-starter-webflux，再结合WebSocketHandler实现全链路响应式
严格控制线程栈大小与数量
即便采用异步模型，网关层仍需管理少量关键线程（如心跳调度、消息广播、连接认证），需精细化配置：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 将
-Xss从默认 1MB 降至 256KB 或 512KB（例如：-Xss512k），前提是确认业务逻辑无深层递归或大局部变量 - 限制线程池最大线程数：比如用于 SSL 握手、HTTP 升级请求的线程池，设为
core=4, max=16，避免突发大量握手请求创建过多线程 - 禁用未使用的线程池：关闭 Tomcat 的
acceptorThreadCount和pollerThreadCount（若已切 Netty），防止冗余线程残留
剥离长连接与业务逻辑的线程耦合
网关应专注连接生命周期管理，不参与消息解析、路由、存储等耗时操作：
- 收到 WebSocket 帧后，只做基础校验（如 token 解析、IP 限流）、序列化为轻量对象（如
WsFrameEvent），立即投递到异步队列（如Disruptor或LinkedBlockingQueue） - 由独立的业务线程池消费队列，执行鉴权、Redis 查询、消息组装等；该池线程数按 CPU 密集型（≈核数）或 IO 密集型（≈核数×2~4）设置，与连接数解耦
- 广播消息时，避免在 I/O 线程中遍历所有 Session 并同步 write：改为批量收集目标连接 ID，交由专用广播线程异步推送
启用连接复用与连接保活分级
减少无效连接对线程资源的隐性占用：
- 在网关层实现连接复用策略：同一客户端 IP+User-Agent 组合，在短时间（如 30 秒）内重复建连，优先复用已有连接句柄，拒绝新建
- 区分连接等级：普通用户连接使用标准心跳（30s ping/pong）；后台管理连接或设备连接启用更宽松的超时（如 5 分钟无数据才断开），降低重连风暴频率
- 接入层 Nginx 配置
proxy_read_timeout 300与proxy_send_timeout 300，确保代理不因超时主动 kill 连接，导致客户端频繁重建连接并触发新线程分配
