Spring AMQP 队列删除后重建及监听器容器无法停止问题

• 新版Spring AMQP调整了消费者终止事件的处理逻辑：触发ListenerContainerConsumerTerminatedEvent后，容器并不会主动进入停止状态，会在后台持续执行重试消费逻辑，导致原有轮询判断listenerContainer.isRunning()永远返回true，等不到容器自然停止。
• 未显式中断旧容器的后台重试流程：旧容器会在队列重建完成后自动恢复消费，和新启动的容器共同绑定同一队列，最终出现监听器数量从5个翻倍到10个的叠加效果。
• 配置逻辑不匹配：手动将底层ConnectionFactory的automaticRecoveryEnabled设为false，但未同步关闭CachingConnectionFactory层面的自动重试恢复逻辑，两层恢复机制和手写的容器重建逻辑产生冲突。

• 替换原有轮询等待容器停止的逻辑：无需被动轮询判断isRunning()状态，拿到旧容器引用后，主动调用带超时参数的停止接口：

  // 原轮询等待逻辑全部替换为主动停止
  this.listenerContainer.stop(10000); // 超时时间单位为毫秒，超时后强制终止容器内所有消费线程、打断重试循环
  

  从Spring AMQP 2.0+版本开始，该方法会主动中断容器内部的消费者重试任务，不会让线程在后台静默挂起。
• 对齐连接工厂的恢复配置，避免两层恢复逻辑冲突：

  // 保留原有ConnectionFactory配置不变，补充CachingConnectionFactory的匹配参数
  ccf.setRecoveryInterval(0); // 关闭CachingConnectionFactory层面的自动恢复，和底层连接工厂关闭自动恢复的配置对齐
  

• 修正重建流程的对象引用逻辑，防止旧容器线程干扰新容器初始化：

  private void recreateContainer() {
    if (this.recreatingContainer.compareAndSet(false, true)) {
      // 长期复用单线程Executor即可，无需每次重建都新建线程池，避免资源泄漏
      executor.execute(() -> {
        // 暂存当前旧容器引用，将类变量中的旧引用置空
        MessageListenerContainer oldContainer = this.listenerContainer;
        this.listenerContainer = null;
        // 主动停止旧容器，最多等待5秒完成停止
        oldContainer.stop(5000);
        // 确认旧容器停止完成后，再启动新容器
        startNewContainer();
        this.recreatingContainer.set(false);
      });
    }
  }
  

• 适配新的事件监听逻辑：将原有监听的ListenerContainerConsumerFailedEvent替换为ListenerContainerConsumerTerminatedEvent，保留原有“判断触发事件的源容器是否和当前持有的容器一致”的校验逻辑即可，无需额外增加状态判断。
• 特殊场景适配：如果使用的是DirectMessageListenerContainer，需要在容器初始化时设置合理的consumeTimeout参数，避免长轮询阻塞stop方法的执行。

内容的提问来源于stack exchange，提问作者Bojan Vukasovic