rabbittemplate 线程安全因其无共享可变状态，所有操作委托给线程安全的 connectionfactory（如 cachingconnectionfactory）；但高并发问题多源于 connectionfactory 配置不当，如 channelcachesize 过小、未设 connectionlimit 或未启用 publisher-confirm-type。

RabbitTemplate 本身是线程安全的，但它的线程安全性完全依赖于底层 ConnectionFactory 的实现和配置方式。直接用默认单例 Bean 并发调用不会崩溃，但不等于“高并发下不出问题”。

为什么 RabbitTemplate 被认为线程安全？

它内部不维护可变的请求级状态（比如连接、通道、响应体），所有实际 I/O 操作都委托给 ConnectionFactory 创建的 Channel。只要 ConnectionFactory 是线程安全的（Spring AMQP 默认的 CachingConnectionFactory 就是），且你没手动复用或缓存 Channel，那么多个线程并发调用 convertAndSend() 或 receive() 不会互相污染。

• RabbitTemplate 实例本身无共享可变状态 —— 所有参数（如 exchange、routingKey、message）都是方法入参，不写入实例字段
• 消息转换器（MessageConverter）、回调（ConfirmCallback、ReturnCallback）若为无状态对象，也天然支持并发
• Spring Boot 自动装配的 RabbitTemplate Bean 默认使用 CachingConnectionFactory，该工厂对 Channel 做了线程安全的缓存与复用

并发下最常踩的坑：ConnectionFactory 配置不当

线程安全 ≠ 高性能。很多线上故障不是因为“报错”，而是连接耗尽、响应延迟飙升、CPU 持续拉满——根源几乎都在 ConnectionFactory 配置上。

• 默认 CachingConnectionFactory 的 channelCacheSize 是 25，但这是每个连接的 Channel 缓存数，不是总并发上限；如果消费者/生产者线程数远超此值，会频繁创建销毁 Channel，引发锁竞争
• 未设置 connectionLimit（Spring AMQP 2.4+ 支持）时，高并发下可能建立过多 TCP 连接，触发系统 ulimit 限制，出现 java.io.IOException: Too many open files
• 未启用 publisher-confirm-type: correlated + mandatory: true 时，消息静默丢失，压测时看似“成功”，实则大量消息未进队列
• 在异步线程（如 @Async、定时任务、WebFlux Mono.subscribe()）中复用同一个 RabbitTemplate 实例没问题，但若在这些场景里手动调用 createChannel() 并长期持有，就会破坏线程安全前提

需要多实例 RabbitTemplate 的真实场景

不是“为了线程安全”而多例，而是为了隔离配置。单例 RabbitTemplate 无法同时满足不同业务线对确认机制、重试策略、超时、消息头处理的差异化要求。

• 必须用 @Scope("prototype") + @Bean 声明，否则 Spring 仍返回单例引用
• 每个 prototype 实例需独立设置 setConfirmCallback() 和 setReturnCallback()，不能共用同一回调对象（除非该对象本身无状态且线程安全）
• 不要在 prototype 实例里缓存 CorrelationData 或修改其 id 字段并跨线程复用 —— CorrelationData 是一次性的，重复使用会导致回调匹配错乱
• 若使用 BatchingRabbitTemplate，它不是线程安全的，必须按需 new 实例，绝不可作为 Bean 注入共享

真正容易被忽略的是：线程安全只保底不崩溃，但性能瓶颈、消息可靠性、错误可观测性，全靠 ConnectionFactory 参数、publisher-confirm-type 类型、以及是否正确绑定 CorrelationData 来兜底。别只盯着 RabbitTemplate 本身。