websocket服务端高并发瓶颈在于应用层连接管理、消息分发、内存控制与资源调度；需落实背压控制（如drain监听）、分级生命周期管理、禁用压缩、异步广播分片及前端worker卸载计算。
WebSocket 本身不处理服务器压力，它只是协议。真正扛不住高并发的，是服务端应用层——连接管理、消息分发、内存控制和资源调度这四块一松动，几万连接就能把 Node.js 进程拖垮。
关键不是“怎么连”，而是“怎么管”和“怎么发”
uWebSockets.js 或 ws 库跑得再快，若没配对背压、没控住缓冲、没拆开读写逻辑，连接数一上万，内存就飙、GC 就抖、连接就静默断。
背压控制必须落地到 send() 的每一行
服务端 WebSocket 发送不是“调用即送达”。底层 TCP 缓冲区 + 应用层待写队列加起来，就是 getBufferedAmount() 返回的值。这个值超了，消息就堆在内存里。
-
maxBackpressure: 1024 * 1024（1MB）是安全阈值，设太大单连接吃掉几十 MB，千连即崩 -
closeOnBackpressureLimit: false必须关掉，否则等触发时用户已断开，体验全毁 - 不要在
send()后立刻查getBufferedAmount()—— 它还没进队列，返回 0 是假象 - 正确做法：监听
ws.on('drain', ...)，或每 100ms 轮询一次，连续 3 次 ≥80% 阈值就暂停发送、降频重试
前端也得配合：别一股脑 for (let i = 0; i ，浏览器单域名最多 6 个并发，Node.js 端要加 <code>setImmediate() 或 setTimeout(..., 0) 分散建连节奏，防 SYN 包风暴。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
连接不能只存内存，得有分级生命周期管理
每个连接都绑一个 WebSocket 实例，还存着用户 ID、权限、订阅频道……不清理，就是内存泄漏。
- 用
Map或ConcurrentHashMap（Java）/new Map()（JS）存活跃连接，键用唯一 session ID，别用Array.push() - 设置空闲超时：
ws.lastMessageTime记录最后收包时间，后台定时扫，超 5 分钟无活动就ws.close(4401, 'idle timeout') - 关闭前清引用：
map.delete(id)、clearTimeout(heartbeatTimer)、off('message')全部手动解绑 - 禁用压缩（
compression: null）可让单连接内存从 64KB 降到 14KB，十万连省下近 5GB
广播不能 for 循环，必须异步扇出 + 分组限流
向 10 万个客户端发同一条公告，逐个 ws.send() 是串行阻塞，耗时秒级，CPU 直接拉满。
- 把广播转成生产者-消费者模型：消息进 Redis Pub/Sub 或 Kafka，每个 worker 节点消费后，只推给本节点负责的连接
- 若不用中间件，至少做分片：按连接 ID 取模分 16 组，每组用
Promise.allSettled()并发推送 500 条，组间加await delay(10)防打爆 - 写操作加锁：多个业务逻辑可能同时往同一连接写，用
writeLock（Go）或mutex（Node.js 的async-mutex）包保护ws.send()
前端也要卸载计算压力，Worker 是刚需
主线程每秒收 200 条消息，JSON.parse() + setState() + render() 全挤在 60fps 里，UI 立刻冻结。
- Web Worker 接管三件事：解析（
JSON.parse或二进制解包）、过滤（剔除无效字段）、聚合（按 100ms 合并行情数据） - 通信用
MessageChannel+Transferable（如ArrayBuffer），零拷贝传数据，避免postMessage序列化瓶颈 - Worker 生命周期必须和服务端连接对齐：页面卸载、重连、切频道时，主线程主动
postMessage({ type: 'reconnect', channel: 'news' })
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
