Dinky项目中WebSocket死锁问题的分析与解决

问题背景

在Dinky项目的1.2.0版本中，管理员界面出现了一个严重的性能问题：整个页面会突然卡死无响应。通过分析日志和线程转储，发现这是由于WebSocket通信中的死锁问题导致的。这个问题主要出现在用户长时间使用系统，特别是涉及CDCSOURCE功能读取远程JAR文件时。

问题现象

系统日志中频繁出现以下错误信息：

Error sending sse data:UT000094: Blocking await method called from IO thread. Blocking IO must be dispatched to a worker thread or deadlocks will result.

线程转储分析显示，多个I/O线程处于TIMED_WAITING状态，等待在WebSocket的发送操作上，形成了典型的死锁场景。这些线程卡在io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.awaitWritable方法中，等待通道变为可写状态。

技术分析

根本原因

1. 线程模型问题：Undertow框架的I/O线程被阻塞式调用占用，违反了Reactor模式的基本原则。在WebSocket处理中，不应该在I/O线程上执行阻塞操作。

2. WebSocket管理缺陷：GlobalWebSocket类中的sendTopic方法直接使用了阻塞式的sendTextBlocking调用，而没有将操作分发到工作线程池。

3. 连接管理不完善：系统在用户登录/登出时没有正确处理WebSocket连接的创建和销毁，导致连接泄漏。

影响范围

这个问题会导致：

• 系统响应变慢甚至完全无响应
• WebSocket消息丢失
• 系统资源(线程、内存)被无效占用
• 用户体验严重下降

解决方案

修复措施

1. 异步发送机制：将阻塞式的WebSocket发送操作改为异步方式，避免占用I/O线程。

2. 线程池分发：引入专门的工作线程池处理WebSocket消息发送，与I/O线程隔离。

3. 连接生命周期管理：

   • 实现WebSocket连接的自动重连机制
   • 确保登出时正确关闭连接
   • 添加连接状态监控

实现细节

在GlobalWebSocket类中，重构消息发送逻辑：

• 使用sendTextAsync替代sendTextBlocking
• 添加消息队列和重试机制
• 实现连接状态回调处理

最佳实践建议

1. WebSocket使用规范：

   • 避免在I/O线程上执行任何阻塞操作
   • 为不同类型的消息设置优先级队列
   • 实现消息确认和重传机制

2. 性能监控：

   • 添加WebSocket连接数和消息吞吐量监控
   • 设置合理的超时时间
   • 实现熔断机制防止雪崩效应

3. 测试策略：

   • 增加长时间稳定性测试
   • 模拟高并发场景下的WebSocket行为
   • 实施混沌工程测试网络不稳定性下的表现

总结

WebSocket在实时数据处理系统中扮演着重要角色，但其使用不当很容易导致系统级问题。Dinky项目中的这个案例展示了WebSocket死锁的典型表现和解决方案。通过将阻塞操作改为异步、合理管理连接生命周期、完善错误处理机制，可以有效避免类似问题的发生。对于类似架构的系统，建议在设计初期就考虑WebSocket的线程模型和资源管理策略。