优雅停用simplemessagelistenercontainer需先设开关拒绝新消息，再等待存量处理完成，最后调用stop()；直接stop会导致消息丢失、重复消费或auto-delete队列被删。
直接停掉 SimpleMessageListenerContainer 容器而不做任何协调，大概率导致消息丢失或重复消费。关键不是“能不能停”，而是“在什么时机、用什么方式停”。
stop() 方法会清空消费者但不等消息处理完
调用 container.stop() 会立即终止内部的 BlockingQueueConsumer 线程，并中断正在拉取或等待分发的消息。它不会等待当前正在 onMessage() 中执行的业务逻辑结束。
- 如果业务逻辑耗时较长（比如调用外部 HTTP、写 DB），
stop()后线程被中断，事务可能未提交，消息也未 ack -
auto-delete队列在容器 stop 后会被 broker 自动删除，重启时若没配置自动重建，监听就彻底失效 - 日志里常见
Consumer cancelled due to exception或Channel closed，其实是 stop 触发的连锁反应
RabbitListenerEndpointRegistry.stop() 的实际行为
这个方法本质是遍历所有注册的 MessageListenerContainer 并调用各自的 stop()，和手动调用单个容器的 stop() 没有本质区别——仍是“立即终止”，不带等待。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 它适合用于“快速下线 + 无状态消费”的场景，比如临时关闭灰度流量
- 不适合“必须处理完积压消息再停”的运维要求
- 注意：若容器绑定了
auto-delete队列，调用后队列消失，后续start()会失败，除非你显式配置了RabbitAdmin自动声明
真正可控的优雅关闭：结合 shutdown hook + 容器状态控制
核心思路是：先拒绝新消息进入处理流程，再等存量消息自然完成，最后调用 stop()。不能只靠 Spring 生命周期回调，得自己加一层控制开关。
- 定义一个 volatile 状态变量
volatile boolean isShuttingDown = false，全局可见 - 在
@RabbitListener方法开头加判断：if (isShuttingDown) { channel.basicReject(deliveryTag, true); return; } - 注册 JVM shutdown hook，在其中设置
isShuttingDown = true，然后 sleep 等待几秒（比如 3–5s），再调用container.stop() - 更稳妥的做法是配合
ApplicationRunner或@EventListener<contextclosedevent></contextclosedevent>，在 Spring 上下文关闭前触发上述流程
auto-delete 队列必须额外处理
这是最容易被忽略的坑。只要容器 stop，broker 就会删掉 auto-delete 队列，哪怕你只是想暂停监听。
- 要么改用非
auto-delete队列（推荐），由运维统一管理生命周期 - 要么在
stop()前手动调用rabbitAdmin.declareQueue(queue)确保队列存在（但要注意并发竞争） - Spring AMQP 2.0+ 提供了
setMissingQueuesFatal(false)，可避免容器因队列不存在而启动失败，但它不解决 stop 后队列被删的问题
真正难的不是调哪个方法，而是判断“当前还有没有消息在途”。JVM shutdown hook 和 Spring Context 关闭事件的触发时机不同，isShuttingDown 开关得覆盖两者；而 basicReject(..., true) 是否重入队列，又得看你的业务能否容忍重复——这些细节一旦漏掉，平滑下线就变成“看起来平滑，实际丢数据”。
