IBM MQ JMS监听器状态查询及Spring并发线程不足问题解决

一、解决单实例下队列监听数量受限的问题 #

你当前的核心问题是JMS监听容器的线程资源不足，导致无法同时为所有队列创建监听器。默认情况下，Spring的DefaultJmsListenerContainerFactory最大线程数为5，当队列数量超过这个值时，后续队列无法分配到线程资源。

解决方法：

• 调整JmsListenerContainerFactory的线程池配置，增大最大并发线程数：

  @Bean
  public DefaultJmsListenerContainerFactory jmsListenerContainerFactory(ConnectionFactory connectionFactory) {
      DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
      factory.setConnectionFactory(connectionFactory);
      // 设置并发范围，最小1个线程，最大15个线程，覆盖默认的5
      factory.setConcurrency("1-15");
      // 也可以直接固定线程数，比如10
      // factory.setConcurrency("10");
      return factory;
  }
  

  注意：你代码中给每个SimpleJmsListenerEndpoint设置的jmsMessageConcurrency是单个队列的监听线程数，需要确保容器工厂的总线程资源能覆盖所有队列的线程需求。比如10个队列每个用1个线程，工厂最大并发至少要设为10。

• 检查jmsMessageConcurrency的配置值，如果单个队列设置了过高的线程数（比如5），10个队列就需要50个线程，此时必须同步调大容器工厂的线程池上限。

二、多实例部署下的队列监听分配（避免重复监听） #

针对多实例部署时的队列监听分配问题，推荐两种可靠方案，替代手动数据库锁：

1. 基于Redis/ZooKeeper的分布式锁 #

分布式锁能解决应用崩溃时锁无法释放的问题：Redis的Redisson锁自带超时自动释放+看门狗续期机制，ZooKeeper锁会在会话断开时自动释放。

• 核心流程：每个实例启动时遍历队列列表，对每个队列尝试获取分布式锁，获取成功则创建监听器，失败则跳过。
• 示例（Redisson实现）：

  @Autowired
  private RedissonClient redissonClient;
  
  public void registerQueueListeners(List<String> queueList) {
      int i = 0;
      for (final String queueName : queueList) {
          // 为每个队列生成唯一锁键
          RLock lock = redissonClient.getLock("queue-listener-lock:" + queueName);
          try {
              // 10秒内尝试获取锁，成功则持有锁（看门狗自动续期）
              if (lock.tryLock(10, TimeUnit.SECONDS)) {
                  // 检查当前实例是否已注册该队列监听器，避免重复注册
                  boolean isRegistered = checkIfEndpointRegistered(queueName);
                  if (!isRegistered) {
                      SimpleJmsListenerEndpoint endpoint = new SimpleJmsListenerEndpoint();
                      endpoint.setId("demo-" + i++);
                      endpoint.setDestination(queueName);
                      endpoint.setConcurrency(jmsMessageConcurrency);
                      endpoint.setMessageListener(message -> {
                          queueController.recv(queueName, message);
                      });
                      registrar.registerEndpoint(endpoint);
                  }
              }
          } catch (InterruptedException e) {
              Thread.currentThread().interrupt();
          } finally {
              if (lock.isHeldByCurrentThread()) {
                  lock.unlock();
              }
          }
      }
  }
  
  // 辅助方法：检查当前实例是否已注册目标队列的监听器
  private boolean checkIfEndpointRegistered(String queueName) {
      return registrar.getEndpointRegistry().getAllEndpoints().values().stream()
              .anyMatch(endpoint -> queueName.equals(((SimpleJmsListenerEndpoint) endpoint).getDestination()));
  }
  

2. 利用JMS中间件的集群监听特性 #

如果你的JMS中间件支持集群级别的队列负载均衡，可直接依赖中间件特性实现自动分配：

• ActiveMQ：给队列设置exclusive="true"，同一时间仅一个消费者能监听该队列，消费者断开时自动切换到其他实例。
  配置示例：

  // 创建Endpoint时，给队列添加独占消费者属性
  endpoint.setDestinationName("queue://" + queueName + "?jms.exclusive=true");
  

• RabbitMQ：使用Consumer Group特性，同一队列的消息只会被组内一个实例消费。
  优势：无需自行实现锁逻辑，由中间件自动处理监听分配，实例崩溃时自动切换，可靠性更高。

三、补充建议 #

• 单实例场景优先调整容器工厂的线程池配置，这是最直接的解决方案，无需引入额外组件。
• 多实例场景优先考虑JMS中间件自身的集群特性，其次选择分布式锁方案，规避手动数据库锁的缺陷。

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