RabbitMQ AUTO确认模式消息未ack及消费者启动线程不足问题排查

问题根因总述 #

两个问题高度关联，核心是SimpleMessageListenerContainer（以下简称SMLC）的线程调度模型、默认批量确认逻辑和你当前的多队列配置不匹配导致的。

1. 消息长期未确认的原因 #

你对AcknowledgeMode.AUTO的理解存在偏差：Spring定义的AUTO确认不等于RabbitMQ原生的自动确认，原生自动确认是消息投递给消费者就直接标记为已确认，而Spring的AUTO是由框架统一控制ack时机，默认采用批量确认策略：

• 只有当消费者线程累计处理的消息数达到prefetchCount阈值、或消费者线程空闲超时、或容器关闭时，才会统一发送批量ack给RabbitMQ
• 你没有显式配置prefetchCount，结合你每个队列攒6条、共300条才触发确认的现象，刚好匹配你设置的最大5个消费者线程的默认拉取策略：单个消费者线程会负责你动态注册的10个队列的消费，提前拉取的消息在RabbitMQ端会直接标记为unacked，由于你的队列生产速率极低，迟迟凑不够批量ack的阈值，就会长期处于未确认状态。
• 你之前用MANUAL模式运行正常，是因为手动ack不受框架批量策略限制，处理完一条就可以立即回传ack，自然不会出现长期unacked的问题。

2. 「线程不足」报错的解决方案 #

这个报错是因为SMLC要启动新的消费者线程时，你绑定的rabbitConsumersExecutorService没有足够的可用线程分配，你之前单纯调大线程数没用，是因为没有匹配SMLC的线程模型做配套调整，完整的修复步骤如下：

• 调整预拉取配置：显式给SMLC设置it.setPrefetchCount(1)，单条消息处理完就触发ack，不需要等待批量；如果需要保留批量确认提升性能，可以根据生产速率设为2-3的小值即可。
• 调整并发消费者配置：你动态注册了50个队列，当前最大仅5个消费者线程完全不足以支撑，建议将setMaxConcurrentConsumers调整为10~20，根据实际消费负载调整即可，注意SMLC的消费者线程是长期存活的，不要设置过大浪费资源。
• 修正自定义线程池配置：确保你自定义的rabbitConsumersExecutorService的最大线程数 ≥ SMLC的maxConcurrentConsumers + 至少5个缓冲线程，同时不要把线程池的等待队列容量设置过大，避免消费者启动任务长期排队触发超时报错。
• 可选优化：更换容器实现：如果你后续还要持续新增队列，更推荐用DirectMessageListenerContainer替换SMLC，它采用单队列绑定单消费者线程的模型，更适合多队列动态注册的场景，不会出现单个线程负载多个队列导致的消息堆积问题。
• 可选：关闭批量确认：如果要保留AUTO模式又不想等待批量，可以显式设置it.setBatchAcknowledgmentEnabled(false)，强制每条消息处理完立即回传ack。

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