1. 为什么WebSocket并发发送消息会出问题？

最近在做一个实时通知系统时，遇到了一个让人头疼的问题：当多个线程同时往同一个WebSocket连接发送消息时，服务端会抛出 IllegalStateException 异常，错误信息显示远程endpoint处于 [TEXT_PARTIAL_WRITING] 状态。这个问题看似简单，但背后涉及WebSocket协议的核心机制。

WebSocket协议在设计上就是 半双工 的，这意味着同一时间只能有一个方向的通信（发送或接收）。虽然底层TCP连接是全双工的，但WebSocket协议层通过状态机来管理消息的发送过程。当你在高并发场景下，多个线程同时调用 session.sendMessage() 时，这些线程会竞争同一个endpoint的写入权，导致状态机混乱。

举个生活中的例子：想象WebSocket连接就像一条单车道隧道，虽然隧道本身可以双向通行（类比TCP全双工），但交通信号灯（WebSocket状态机）规定同一时间只允许一个方向的车辆通过。如果多辆车（线程）不顾信号灯强行同时进入隧道，必然会造成交通事故（状态异常）。

2. 三种线程安全解决方案对比

2.1 方案一：同步锁方案

这是最直观的解决方案——给发送操作加锁。我在最初遇到问题时，第一反应也是这样实现的：

private final Object lock = new Object();

public void sendMessage(WebSocketSession session, TextMessage message) throws IOException {
    synchronized(lock) {
        if (session.isOpen()) {
            session.sendMessage(message);
        }
    }
}

优点 ：

• 实现简单，几行代码就能解决问题
• 不引入额外依赖，适合简单场景

缺点 ：

• 锁粒度太粗，所有会话共享同一把锁
• 并发量高时性能下降明显（实测QPS下降40%+）
• 容易造成线程阻塞，影响系统响应速度

我在压力测试时发现，当并发用户超过500时，平均响应时间从50ms飙升到300ms。这是因为所有发送请求都在排队等待同一把锁，完全失去了WebSocket高并发的优势。

2.2 方案二：官方装饰器方案

Spring官方其实早就预见到了这个问题，提供了 ConcurrentWebSocketSessionDecorator 这个神器。它的实现非常精妙：

@Override
public void afterConnectionEstablished(WebSocketSession session) {
    // 每个会话独立装饰，参数分别是：原始会话、发送超时(ms)、缓冲区大小(bytes)
    WebSocketSession safeSession = new ConcurrentWebSocketSessionDecorator(
        session, 1000, 1024 * 1024);
    sessions.put(session.getId(), safeSession);
}

这个装饰器内部做了三件事：

1. 为每个会话维护一个消息队列（LinkedBlockingQueue）
2. 使用单独的ReentrantLock控制发送流程
3. 提供缓冲区溢出保护策略（TERMINATE/DROP）

核心参数调优建议 ：

• 发送超时：根据消息大小设置，通常1-5秒
• 缓冲区大小：根据业务峰值流量设置，建议至少1MB

实测下来，这个方案在万级QPS下依然稳定，CPU利用率比方案一低30%。唯一的不足是缓冲区满了会丢弃消息，需要业务层做重试机制。

2.3 方案三：事件队列方案

对于超高性能场景，可以参考Tomcat的NIO实现思路，将消息发送改为事件驱动模型：

// 自定义事件队列
private final ExecutorService executor = Executors.newSingleThreadExecutor();
private final BlockingQueue<SendTask> queue = new LinkedBlockingQueue<>(10000);

public void sendAsync(WebSocketSession session, String message) {
    queue.offer(new SendTask(session, message));
}

private class SendTask implements Runnable {
    // 实现略...
}

@PostConstruct
public void init() {
    executor.submit(() -> {
        while (!Thread.interrupted()) {
            SendTask task = queue.take();
            try {
                task.run();
            } catch (Exception e) {
                // 错误处理
            }
        }
    });
}

这种方案的 黄金组合 是：

• 单线程消费队列保证顺序性
• 无界队列+背压控制防止OOM
• 异步非阻塞提交任务

在百万级消息推送系统中，这种架构可以将吞吐量提升5倍以上。当然实现复杂度也最高，需要处理会话生命周期、异常恢复等问题。

3. 性能压测数据对比

我用JMeter对三种方案做了对比测试（4核8G云服务器）：

方案	100并发QPS	500并发QPS	错误率	CPU使用率
原始方案	1,200	崩溃	98%	90%+
同步锁方案	800	350	0%	75%
官方装饰器方案	3,500	2,800	<0.1%	45%
事件队列方案	6,200	5,500	0%	60%

关键发现：

1. 原生方案在高并发下完全不可用
2. 同步锁方案稳定性好但性能损失大
3. 事件队列方案性能最优，但实现复杂度高

4. 如何选择合适方案？

根据我的实战经验，给出以下决策建议：

选择同步锁方案当 ：

• 并发量低（<100QPS）
• 系统资源有限
• 快速修复线上问题

选择官方装饰器当 ：

• 中等并发（100-10k QPS）
• 需要平衡性能和复杂度
• 对消息丢失有一定容忍度

选择事件队列当 ：

• 超高并发（>10k QPS）
• 系统已有多线程基础设施
• 需要极致性能

特别提醒：如果使用Spring STOMP协议，直接使用 SimpMessagingTemplate 即可，它内部已经实现了线程安全机制。

5. 避坑指南

在实施过程中，我踩过几个值得分享的坑：

1. 会话关闭问题 ：即使使用了装饰器，也要记得在 afterConnectionClosed 中移除会话引用，否则会导致内存泄漏。建议使用 ConcurrentHashMap 存储会话。

2. 缓冲区设置 ：装饰器的缓冲区大小设置过小会导致频繁断开连接。根据业务消息体大小，建议至少设置为平均消息大小的100倍。

3. 异常处理 ：一定要实现 handleTransportError 方法，否则网络闪断会导致线程阻塞。我遇到过因为没处理IO异常导致整个线程池挂掉的事故。

4. 心跳检测 ：长时间空闲连接会被防火墙断开，建议实现Ping/Pong机制。Spring的 ServletServerContainerFactoryBean 可以配置心跳间隔：

@Bean
public ServletServerContainerFactoryBean createWebSocketContainer() {
    ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
    container.setMaxSessionIdleTimeout(30000L); // 30秒心跳
    return container;
}

5. 监控指标 ：对于生产环境，建议监控以下指标：
   • 活跃连接数
   • 消息积压量
   • 发送失败率
   • 平均延迟

可以在装饰器上通过 getBufferSize() 等方法获取运行时状态。