WebSocket高并发下拒绝策略关键看业务是否允许延迟、容忍重复及有无持久化兜底，盲目用CallerRunsPolicy或AbortPolicy易压垮连接层或丢消息；必须采用“内存有界+溢出落盘+补偿执行”方案，隔离线程池并自定义RedisBackupPolicy。
WebSocket 高并发场景下，线程池拒绝策略不能只看“不抛异常”或“不丢任务”，关键得看你的业务是否允许延迟、能否容忍重复、有没有持久化兜底能力。盲目用 CallerRunsPolicy 或默认 AbortPolicy，很容易在流量高峰时直接压垮连接层或丢消息。
为什么 WebSocket 场景下拒绝策略特别容易出问题
WebSocket 是长连接，但业务逻辑（比如消息广播、状态同步、心跳响应）仍走线程池。一个连接可能触发多个异步任务；而前端重连、批量推送、消息积压会瞬间打满队列。此时：
-
AbortPolicy→ 抛RejectedExecutionException，若没被@Async的异常处理器捕获，就静默失败，前端收不到回执 -
DiscardPolicy→ 任务直接消失，用户看到“发了消息但没人响应” -
CallerRunsPolicy→ 提交线程（可能是 Netty 的 IO 线程）被迫执行业务逻辑，阻塞事件循环，引发连接超时、心跳断开 - 用无界队列（
LinkedBlockingQueue）→ 内存持续增长，GC 频繁，最终 OOM，整个服务不可用
必须搭配有界队列 + 自定义拒绝策略
WebSocket 场景下，真正可用的方案是「内存有界 + 溢出落盘 + 补偿执行」，而不是在四种内置策略里挑一个凑合。核心动作包括：
- 把
setQueueCapacity设为明确值（如 50～200），绝不用 -1 或默认无界 - 拒绝策略必须重写
RejectedExecutionHandler，且逻辑是：序列化任务 → 存 Redis/DB → 返回成功响应给前端 - 所有任务需实现
PersistableTask接口，含getTaskId()，保证幂等和去重 - 另起一个低频调度任务（如每 5 秒检查一次 Redis 队列），把溢出任务重新
submit到主线程池
示例拒绝策略片段：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
public class RedisBackupPolicy implements RejectedExecutionHandler {
private final String redisKey = "ws:overflow:queue";
private final RedisTemplate<String, byte[]> redisTemplate;
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
if (r instanceof PersistableTask task) {
try {
byte[] data = SerializationUtils.serialize(task);
redisTemplate.opsForList().rightPush(redisKey, data);
} catch (Exception e) {
// 记录告警，但不 throw，避免中断调用方
log.warn("Failed to persist task {} to Redis", task.getTaskId(), e);
}
}
}
}
WebSocket 相关线程池要和业务线程池隔离
别把 WebSocket 消息处理、心跳检测、广播推送全塞进同一个线程池。它们的 SLA 不同：
-
websocket-io-pool：专用于 Netty 的EventLoopGroup，不配置拒绝策略（由 Netty 自己管） -
websocket-task-pool：处理 onMessage、onClose 等回调，队列容量小（如 50）、拒绝策略走 Redis 备份 -
websocket-broadcast-pool：负责向成千上万连接广播，线程数可稍高（max=8～16），但必须配DiscardOldestPolicy防止旧消息阻塞新消息
配置示例中，websocket-task-pool 的 setRejectedExecutionHandler 必须是你自己写的 RedisBackupPolicy，而非 ThreadPoolExecutor.CallerRunsPolicy。
最容易被忽略的三个点
一是 Netty 的 EventLoop 和业务线程池完全不是一回事，混淆会导致 CPU 被 IO 线程占满；二是 Redis 持久化失败时，拒绝策略里不能 throw 异常，否则会中断上层调用链；三是补偿任务必须加分布式锁或分片消费，否则多实例部署时会重复执行同一任务。
