vert.x websocket 高并发稳定运行的关键在于合理配置与避坑：必须显式设置空闲超时、帧大小和压缩级别；禁止在事件循环中执行阻塞操作；通过 writequeuemaxsize 和 drainhandler 控制背压；跨 verticle 广播需用轻量消息+连接状态管理。
Vert.x 的 WebSocket 服务在高并发下不崩、不丢帧、不卡顿，关键不在“怎么写”，而在“怎么配”和“怎么避坑”——尤其是连接生命周期管理、消息背压控制、以及事件循环阻塞这三点，90% 的线上问题都出在这里。
WebSocket 连接数上万后频繁断连？检查 HttpServerOptions 的空闲超时与帧大小
默认配置下，Vert.x 的 WebSocket 服务器对长连接非常“宽容”，但这种宽容会反噬：客户端心跳不规范、网络抖动未及时感知、大消息未分帧，都会导致连接被静默关闭。
-
setIdleTimeout(30)是必须显式设置的，单位为秒；不设则用 Netty 默认值（通常为 0，即永不超时），容易积累僵尸连接 -
setMaxFrameSize(1024 * 1024)要匹配业务最大单帧消息（如图片 Base64、设备原始日志），设小了会直接抛WebSocketFrameTooLargeException -
setWebSocketCompressionLevel(6)在 CPU 允许前提下建议开启（尤其 IoT 场景），但注意：客户端必须声明支持permessage-deflate子协议，否则握手失败
webSocketHandler 里别做阻塞操作，哪怕只是 System.out.println
Vert.x 的 webSocketHandler 回调运行在 Event Loop 线程上。任何同步耗时操作（包括日志、JSON 序列化、本地缓存查表）都会拖慢整个线程处理能力，导致后续连接建立延迟、ping/pong 响应超时、甚至触发客户端重连风暴。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 日志务必用异步 logger（如 Logback 的
AsyncAppender），避免FileWriter.write()阻塞 - 消息解析尽量用
Buffer.toJsonObject()而非new JsonObject(buffer.toString())，后者隐含字符串拷贝和 GC 压力 - 若需查本地状态（如用户会话白名单），优先走
ConcurrentHashMap，禁用synchronized方法或ReentrantLock
消息堆积时如何防止 OOM？用 writeQueueMaxSize + drainHandler 控制背压
当客户端消费速度跟不上服务端推送速度（比如监控大盘批量下发、设备固件分片广播），WebSocket.writeTextMessage() 不会阻塞，但内部写队列会持续增长，最终吃光堆内存。
- 创建连接后立即设置：
ws.setWriteQueueMaxSize(1024)（根据消息平均大小调整，通常 512–4096 合理） - 注册背压回调：
ws.drainHandler(v -> { /* 可恢复推送 */ })，并在writeTextMessage前加if (ws.writeQueueFull()) return; - 注意：
drainHandler触发时机依赖底层 Netty 的ChannelWritabilityChangedEvent，不是实时的，要有缓冲余量
如何安全地在多个 Verticle 间广播消息？别直接传 WebSocket 实例
WebSocket 对象不是线程安全的，也不能跨 Verticle 传递。试图在 EventBus 上发送它，会触发 NotSerializableException 或运行时 IllegalStateException。
- 正确做法：只在 EventBus 上发轻量消息（如
{"type":"notify","userId":"u123","data":{...}}），由持有 WebSocket 引用的 Verticle 订阅并转发 - 每个 WebSocket 连接应绑定唯一 ID（可用
ws.textHandlerID()或自生成 UUID），存入ConcurrentMap<string websocket></string>，清理时用ws.closeHandler()反向移除 - 广播前务必检查
ws.readyState() == OPEN，避免IllegalStateException: Connection is closed
真正难的不是写出能跑通的 WebSocket 服务，而是让十万连接同时在线时，每个 ping 都有 pong，每条指令都不丢，每次重连都能续上上下文——这些细节藏在 HttpServerOptions 的字段里、藏在 drainHandler 的判断里、更藏在你没写进 try-catch 的那行 Buffer.toJsonObject() 里。
