Jedis.subscribe()必须在独立线程中运行，因其是阻塞同步调用，会独占Socket连接并卡死当前线程，直至断连或显式取消；若在主线程或Web线程中调用，将导致线程池耗尽、请求挂起。
为什么Jedis.subscribe()必须在独立线程里跑
subscribe() 是阻塞同步调用，一执行就卡死当前线程，直到连接断开或显式unsubscribe()。这不是 Redis 服务端卡住，而是 Jedis 客户端的设计使然——它把整个订阅生命周期绑定在单个 Socket 连接上，且不提供非阻塞 API。
常见错误是直接在主线程或 Web 请求线程里调用 jedis.subscribe(subscriber, "ch")，结果整个服务线程池被耗尽，HTTP 请求全挂起。
- 必须用
new Thread(() -> { ... }).start()或ExecutorService单独起线程运行订阅逻辑 - 该线程只负责监听，不能复用做其他事；否则一旦阻塞，消息处理和业务逻辑全停摆
- 不要试图在同一个
Jedis实例上调用subscribe()和set()等命令——连接已被订阅独占，后续命令会抛JedisConnectionException
如何避免断连后漏收消息
Jedis 没有内置重连回调，JedisConnectionException 抛出即线程退出，旧 JedisPubSub 实例不可复用，channel 订阅状态也不会自动恢复。
手动重连的关键不是“捕获异常后 close 再取新连接”，而是重建整个订阅上下文：
- 每次断连后，必须 新建一个
JedisPubSub子类实例，不能复用旧对象 - 必须显式保存要订阅的 channel 列表（如
String[] channels = {"a", "b"}），断连重试时全量传入subscribe() - 连接池资源要正确释放：
finally块中调jedis.close()，但注意这不等于取消订阅，只是归还连接 - 建议加
Thread.sleep(1000)防止重连风暴，尤其在 Redis 临时不可达时
client-output-buffer-limit 设置不当会触发静默断连
Redis 6.0+ 虽已将 Pub/Sub 分发异步化，但若订阅端消费太慢，其输出缓冲区仍会涨满。一旦突破 client-output-buffer-limit pubsub 配置，Redis 会强制断开连接，且不通知客户端——你看到的就是突然中断、无日志、无异常。
默认值 32mb 8mb 60（软限 32MB / 硬限 8MB / 60 秒）在高吞吐场景下极易击穿：
- 检查方式：
redis-cli config get client-output-buffer-limit，重点关注 pubsub 行 - 调大示例：
config set client-output-buffer-limit "pubsub 256mb 64mb 60"（单位是字节，256mb = 268435456） - 这个配置需写入
redis.conf持久化，否则重启失效 - 调太大也有风险：内存占用飙升，可能触发 OOM；建议结合实际消息速率 + 消费延迟压测后设定
别把 JedisPool 当成万能解药
很多人以为用了 JedisPool 就能自动兜底所有问题，其实它对 Pub/Sub 场景几乎无效——因为 subscribe() 会独占底层连接，连接池无法复用这条连接给其他请求，也无法感知其内部阻塞状态。
真正需要的是分层设计：
- 业务命令（
set/get/hgetall）走JedisPool，保证连接复用和超时控制 - Pub/Sub 专用连接应单独管理：要么直连（
new Jedis(host, port)），要么用独立小池子（maxTotal=1），避免污染主连接池 - 密码配置陷阱：若 Redis 无密码，
JedisPool构造时 password 参数必须为null，传空字符串""会导致认证失败、连接池枯竭
最易被忽略的一点：Jedis 的 subscribe() 不支持超时参数，也没有心跳保活机制，网络抖动或中间设备（如 SLB、防火墙）空闲断连时，它只能等 TCP RST 到来才感知——这期间消息完全丢失，且无任何提示。
