RabbitTemplate本身线程安全，但连接泄漏源于CachingConnectionFactory配置不当：channelCacheSize未限、连接未复用、多实例工厂或环境配置不一致，导致Channel和AMQConnection持续增长引发OOM。
RabbitTemplate 本身不持有连接，但若配置不当或使用方式错误，会间接导致 CachingConnectionFactory 持有的连接、通道（Channel）和缓存对象持续增长，最终引发内存泄漏甚至 OutOfMemoryError。核心问题不在 RabbitTemplate，而在它背后默认依赖的连接工厂行为。
为什么 RabbitTemplate 会“泄露连接”？
这不是 RabbitTemplate 的 bug，而是其默认协作组件的典型误用模式：CachingConnectionFactory 在未显式配置缓存上限、未正确关闭资源、或在非 Spring 管理上下文中反复 new 实例时，会导致：
-
Channel缓存无限增长（默认channelCacheSize=25，但若高并发下短时突发，实际缓存数可能远超） - 每个
Channel关联一个AMQConnection，而连接本身又持有大量缓冲区、线程、心跳任务等资源 - 若应用中手动 new 多个
RabbitTemplate实例（尤其搭配独立的CachingConnectionFactory），每个都会维护一套缓存，加剧泄漏 - Spring Boot 自动配置的
RabbitTemplate默认复用单例CachingConnectionFactory，但若你在 @Configuration 中多次@Bean 它且未设@Scope("singleton")，就可能产生多个工厂实例
如何确认是 CachingConnectionFactory 引起的泄漏？
别急着看代码，先看现象和指标：
- 堆内存中
com.rabbitmq.client.impl.AMQConnection和com.rabbitmq.client.impl.ChannelN实例数随时间线性/阶梯式上涨（用jmap -histo:live <pid></pid>或 MAT 的 Dominator Tree 验证） - GC 日志显示老年代持续增长，Full GC 后回收极少，且
CachingConnectionFactory相关对象（如ChannelCachingConnectionListener）在 GC Roots 中强引用大量Channel - JConsole / JVisualVM 的 MBean 中查看
org.springframework.amqp.rabbit.connection.CachingConnectionFactory对应的Channels属性值不断升高，长期不回落 - 应用日志中频繁出现
java.io.IOException: Connection reset by peer或Attempt to use closed channel—— 往往是连接池混乱后通道被提前关闭又误用
关键修复配置与编码习惯
修复重点不是改 RabbitTemplate，而是约束它的“呼吸系统”——连接工厂：
- 显式配置缓存上限：
spring.rabbitmq.cache.channel.size=10
（生产环境建议 ≤10，避免通道堆积） - 禁用连接缓存（除非你确定连接开销极高）：
spring.rabbitmq.cache.connection.mode=CHANNEL
（即只缓存 Channel，不缓存 Connection；默认就是此值，但务必确认没被覆盖） - 强制设置连接空闲超时（防连接长期闲置不释放）：
spring.rabbitmq.cache.connection.timeout=30000
（单位毫秒） - 确保全局只存在一个
CachingConnectionFactorybean：检查所有@Bean方法是否加了@Scope("singleton")，或直接删掉自定义 factory bean，信任 Spring Boot 自动配置 - 禁止在循环或高频方法内 new
RabbitTemplate：它必须是 Spring 管理的 singleton bean；若需动态路由，用@Qualifier注入多个预配置好的实例，而非运行时构造
最容易被忽略的陷阱：测试环境 vs 生产环境配置差异
很多团队在 application-test.yml 里把 spring.rabbitmq.host 指向本地 Docker RabbitMQ，却忘了同步配置缓存参数。结果测试跑得通，上线后因真实 RabbitMQ 延迟更高、连接建立更慢，CachingConnectionFactory 的通道缓存更容易卡住、堆积。务必保证所有环境的 cache.* 参数一致，并在压测中监控 Channels MBean 数值是否收敛。
