确认消息时遭遇AmqpException: PublisherCallbackChannel is closed异常求助

碰到这个PublisherCallbackChannel is closed的异常确实头疼，结合你用的RabbitMQ 3.5.6和spring-amqp 1.6.1.RELEASE版本，我给你梳理几个实用的排查方向：

1. 先查通道的生命周期是否异常 #

• 首先要确认是不是通道被提前关闭了：spring-amqp的CachingConnectionFactory会缓存通道，如果你在消费逻辑里手动调用了channel.close()，或者RabbitMQ服务器因为超时、资源不足等原因主动关闭了通道，后续再执行basicAck就会触发这个异常。
• 可以开启spring-amqp的DEBUG级别日志，重点关注CachingConnectionFactory相关的日志输出，看看有没有类似Closing cached Channel的记录，这能帮你定位通道关闭的时机和原因。

2. 检查批量确认的时机配置 #

从栈信息能看到你用了AbstractBatchingQueueMessageListener做批量ack，这里容易踩的坑是：

• 批量任务执行时，原来的通道可能已经失效了。比如你的batchTimeout设置得太长，在等待批量积累的过程中，RabbitMQ的连接因为connection_timeout（默认60秒）到期被断开，通道也跟着关闭了。
• 建议检查你的批量参数：比如batchSize（批量大小）和batchTimeout（超时时间），如果超时时间过长，试着调短一些；另外可以在执行批量ack前，先通过Channel.isOpen()判断通道状态，要是通道已经关闭，考虑放弃这批ack或者重新获取有效通道处理。

3. 排查连接重连后的通道复用问题 #

spring-amqp 1.6.x版本的CachingConnectionFactory在连接重连后，旧的失效通道可能没有被正确清理：

• 当RabbitMQ连接断开后，客户端会自动重连，但之前缓存的旧通道已经不能用了，如果你的批量任务还持有旧通道的引用，调用basicAck自然会报错。
• 可以尝试调整CachingConnectionFactory的channelCacheSize参数，或者升级到spring-amqp 1.6.x的后续小版本（比如1.6.14.RELEASE），这个版本修复了一些连接重连后的通道缓存bug。

4. 检查RabbitMQ服务器端的状态 #

• 登录RabbitMQ服务器，查看它的日志文件，看看有没有通道关闭的具体原因，比如channel closed due to exception、内存不足、文件描述符耗尽等。RabbitMQ 3.5.6对资源限制比较严格，要是服务器内存或磁盘空间不够，会主动关闭部分通道。
• 可以用rabbitmqctl list_channels命令查看当前通道的状态，有没有异常关闭的记录。

5. 排查消费逻辑中的异步操作 #

如果你的消费逻辑里有异步操作，并且在异步回调里执行ack，要注意：

• spring-amqp的通道默认是和线程绑定的（THREAD_LOCAL模式），异步线程拿到的通道可能已经被主线程回收失效了。
• 这种情况建议把ack操作放在消费的主线程中执行，或者确保异步操作时持有有效的通道引用。

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