@PreDestroy 对 Redis 订阅监听器失效，因其销毁逻辑不遵循标准 Bean 生命周期；必须通过 DisposableBean 实现 destroy() 并调用 RedisMessageListenerContainer.stop() 才能触发取消订阅、等待消息处理完成、关闭线程及释放资源的完整优雅停机流程。
必须手动调用 RedisMessageListenerContainer.stop()，@PreDestroy 无效，且不能只关连接工厂或连接实例。
为什么 @PreDestroy 对 Redis 订阅监听器完全失效
Spring Boot 3.x（基于 Spring Framework 6+）中，@PreDestroy 方法执行时，RedisMessageListenerContainer 的实际注销流程尚未开始。该容器内部维护着独立的监听线程、长连接和消息分发队列，其销毁逻辑不严格遵循标准 Bean 生命周期——它可能在 @PreDestroy 返回后仍持续接收新消息、持有连接句柄，甚至触发重连。
常见现象包括：
-
CLIENT LIST中仍显示cmd=subscribe的活跃客户端，即使应用进程已退出 - 重启后出现“重复订阅”或“消息堆积未消费”，因旧监听器残留导致多实例并发消费
- 日志反复出现
Connection closed while listening或Subscription already closed警告
必须用 DisposableBean 注入并调用 stop()
RedisMessageListenerContainer 是订阅生命周期的实际管理者，不是 RedisConnectionFactory 或底层 Jedis/Lettuce 连接。只有它能触发完整优雅流程：取消 SUBSCRIBE 命令、等待正在处理的消息完成、关闭监听线程、释放连接资源，并支持超时控制。
实操要点：
- 确保你的
RedisMessageListenerContainer是通过@Bean声明的单例（不要new），否则无法注入 - 在任意
@Component或@Configuration类中实现DisposableBean接口 - 用
@Autowired注入该容器实例，然后在destroy()方法中调用container.stop()（不是destroy()） - 避免直接调用
connection.close()或factory.destroy()—— 容器已接管连接，手动关闭会抛IllegalStateException
搭配 Spring Boot 内置优雅停机使用才真正可靠
单独实现 DisposableBean 不够，必须与 Spring Boot 3 的全局优雅停机机制协同。否则，容器可能在 Web 服务器停止前就被强制中断，或在 JVM Shutdown Hook 执行后才开始清理。
关键配置组合：
- 启用 Web 层优雅停机：
server.shutdown=graceful - 设置整体关闭超时：
spring.lifecycle.timeout-per-shutdown-phase=30s（建议 ≥20s，给订阅停止留足时间） - 确保
RedisMessageListenerContainerBean 的destroyMethod未被覆盖（即不要写@Bean(destroyMethod = "")） - 若使用 Actuator
/actuator/shutdown，需确认其触发的是完整上下文关闭流程（默认是）
最容易被忽略的一点：Redis 订阅的注销不是“断开连接”，而是向服务端发送 UNSUBSCRIBE 指令并同步等待响应；这个过程依赖网络稳定性与超时设置，stop() 的返回不代表服务端已解除订阅，仅表示客户端已终止监听循环。生产环境应配合 CLIENT SETNAME 和定期 CLIENT LIST 巡检验证。
