必须复用Connection并按需创建Channel，禁止一消息一Channel；因每个Channel占用1–2MB堆外内存及文件描述符，高频新建易致OOM或fd耗尽。
直接结论：不要每次发消息都 new Channel，必须复用 Connection + 按需复用 Channel，否则高并发下极大概率触发 OOM。
为什么频繁创建 Channel 会 OOM？
Channel 不是轻量对象，它底层持有 TCP 缓冲区、帧解析器、确认序列号管理器等资源。每创建一个 Channel，JVM 就分配约 1–2MB 堆外内存（由 Netty 或原生 socket 驱动管理），同时占用文件描述符和 Broker 端连接配额。实测中，单机每秒新建超 500 个 Channel，10 分钟内就会因堆外内存泄漏或 fd 耗尽导致 OutOfMemoryError: Direct buffer memory 或 IOException: Too many open files。
Connection 和 Channel 的正确生命周期怎么管？
Connection 是重量级的，应全局单例或使用连接池；Channel 是轻量但非无状态的，适合短生命周期复用，但绝不能“一消息一 Channel”。关键原则：
-
ConnectionFactory可复用，建议 Spring 中声明为@Bean单例 -
Connection必须复用，禁止在业务方法里调用factory.newConnection() -
Channel推荐按业务逻辑边界复用（如一次 HTTP 请求、一个事务），用完立即channel.close()—— 注意不是connection.close() - 若使用 Spring AMQP，优先走
RabbitTemplate，它内部已封装了Channel的自动获取与释放逻辑
手动管理 Channel 时最容易踩的坑
绕过 Spring 直接用原生 client 时，常见错误写法：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
public void send(String msg) {
try (Connection conn = factory.newConnection(); // ❌ 错误：每次新建 Connection
Channel ch = conn.createChannel()) { // ❌ 错误：每次新建 Channel
ch.basicPublish(...);
}
}
正确做法是把 Connection 提到类成员或静态域，Channel 在方法内按需创建并显式关闭：
private final Connection connection; // 复用
public void send(String msg) throws IOException {
try (Channel ch = connection.createChannel()) { // ✅ 每次只新建 Channel，且自动 close
ch.confirmSelect(); // 如需 confirm
ch.basicPublish(...);
ch.waitForConfirms(3000); // 同步等待确认
}
}
注意：try-with-resources 对 Channel 有效，但对 Connection 不适用——它不能被频繁开关。
高并发场景下 Channel 复用要不要加锁？
不需要。RabbitMQ Java Client 的 Channel 是线程不安全的，但它的设计本意就是“每个线程一个 Channel”，而非共享。所以：
- 别把
Channel设成类变量或静态变量供多线程共用 - 也不用
synchronized包裹channel.basicPublish()—— 这只会串行化发送，吞吐暴跌 - 正确姿势：用
ThreadLocal<Channel>缓存当前线程的 Channel，或交由 Spring 的CachingConnectionFactory管理 - 如果用了
CachingConnectionFactory，记得配置setChannelCacheSize(25)，避免缓存过大反而拖慢 GC
真正危险的不是 Channel 本身，而是把它当成 Connection 一样随意 new —— 一旦漏关、复用错线程、或缓存策略失控，OOM 就在下一个高峰流量里等着你。
