会。listener中抛出未捕获的runtimeexception会终止i/o线程，导致onmessage等回调静默失效，连接仍活跃但消息不再分发，lettuce和jedis均不自动恢复或重试。
Listener中抛出RuntimeException会导致订阅中断吗
会。Redis Java客户端（如Lettuce、Jedis）的订阅监听器运行在独立的I/O线程中，RuntimeException未被捕获时会直接终止该监听线程，后续消息不再触发onMessage等回调，但连接本身可能仍处于活跃状态——表现为“看起来连着，却收不到新消息”。
这不是连接断开，而是事件分发链路被异常击穿。Lettuce默认不包装或重试，Jedis的JedisPubSub更是完全透传异常到底层线程。
- 现象：控制台无报错，
onMessage突然静默，PING仍能通 - 根本原因：I/O线程因未捕获异常退出，监听器实例被弃用
- 注意：
try-catch写在onMessage方法体外无效——你没法在父类JedisPubSub或MessageListener接口里加
Lettuce如何安全包裹MessageListener的onMessage
Lettuce推荐用装饰器模式封装原始MessageListener，把所有回调入口统一兜底。不要继承ChannelMessageListener后重写方法，而应构造一个代理对象。
关键点是：异常必须在onMessage、onPatternMessage、onSubscribe等每个回调内单独捕获，不能只包onMessage——订阅确认失败也会中断流程。
- 示例做法：
MessageListener safeListener = new MessageListener() { private final MessageListener delegate = originalListener; @Override public void onMessage(ByteBuffer channel, ByteBuffer message) { try { delegate.onMessage(channel, message); } catch (RuntimeException e) { log.error("Unexpected error in onMessage", e); // 可选：上报指标、触发告警，但不要抛出 } } @Override public void onSubscribe(ByteBuffer channel, long subscribedChannels) { try { delegate.onSubscribe(channel, subscribedChannels); } catch (RuntimeException e) { log.error("Unexpected error in onSubscribe", e); } } // 其他回调同理... }; - 别用
Thread.setDefaultUncaughtExceptionHandler——它对Netty EventLoop线程无效 - Lettuce 6.1+ 提供了
StatefulRedisPubSubConnection，其addListener接受的就是裸MessageListener，不自动包装
Jedis中JedisPubSub的异常处理陷阱
Jedis的JedisPubSub是抽象类，子类实现onMessage等方法，但它的subscribe调用是阻塞式同步执行的——也就是说，异常会直接冒泡到调用线程，而这个线程通常是你的业务线程或定时任务线程。
后果更隐蔽：你以为只是“某个消息处理错了”，实际是整个subscribe()调用提前返回，连接被关闭，且Jedis不会重连。
- 错误写法：
new JedisPubSub() { public void onMessage(String channel, String message) { riskyParse(message); // 这里NPE → subscribe()立即退出 } }.subscribe("my:channel"); - 正确姿势：在每个
onXxx方法内部try-catch，并确保subscribe调用在线程池中执行，避免阻塞主线程 - 注意：
JedisPubSub没有onError钩子，异常无法被回调感知，只能靠日志和监控发现
要不要在Listener里做重试或死信投递
不要。Listener职责是消费，不是业务编排。消息重复、失败补偿、死信路由这些逻辑应该上移到上游服务层，通过幂等+本地事务表+延时队列实现。
在onMessage里手动PUBLISH到另一个channel，容易引发循环消费；sleep后重试会卡住I/O线程；记录DB失败又没回滚机制，反而制造数据不一致。
- 真正要做的只有三件事：打日志（含message ID、channel、堆栈）、发告警（如阈值超限）、更新监控计数器（如
redis_sub_error_total{type="parse"}） - 如果业务强依赖“至少一次”，应在发布端做ACK机制，而非在Listener里补救
- 最容易被忽略的一点：Logback或Log4j的异步Appender在高并发下可能丢日志——确保错误日志走同步输出或带丢失告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
