RocketMQ消息异步发送：玩转 FullGC 与 OOM 的速度与激情
最近在整理自己的笔记，发现一个两年前记录的在业务场景中遇上了一个“趣味”十足的问题：为了让业务解耦，同时利用微服务多节点并发处理的优势，我们选择了自产自消的 MQ 消息方案。看似完美的设计却在数据处理高峰期给我们送上了一份“大礼”——频繁的 FullGC 和甚至是存在 OOM风险，让服务器掉入“性能黑洞”！
一、异步发送 API：看似灵活，实则暗藏杀机
我们使用了 Spring 提供的 RocketMQ 异步发送消息 API，如果你像我一样没有自定义线程池参数，就会默认走系统默认线程池。这个线程池的任务队列默认长度竟然高达 50000！在高并发场景下，异步发送线程一旦处理不过来，任务信息和大量数据就会临时堆积在任务队列中，而线程池的核心线程数和最大线程数只是根据容器所分配的处理器数量而定（核心线程数和最大线程数等于当前系统可用处理器数量）——这绝对不是冠军队伍的配置，而是一场隐蔽的性能瓶颈。 源码如下：
二、Default 配置背后的悲剧
对使用批量消息发送 API 的朋友来说，消息体可能非常庞大。假如你和我一样“幸运”，没自定义线程池，就可能惨遭频繁的 FullGC。想象一下，在极限流量面前，系统疯狂回收内存的场面：满屏的 FullGC 警告，无情地将系统推向崩溃的边缘。如此惨烈的战斗，只有真正的极客才能体会那份刺激。
三、资源争夺：一边生产，一边消费，一个个数据酱舞动的恶性循环
在使用公共组件 API 时，千万别以为“开箱即用”就是万无一失！在极速生产消息的同时，你的异步消费者也在拼命消费，而且两边你争我夺，资源相互竞争，消耗极其巨大。这个场景宛如两支狂野的乐队在同一个小舞台上同时high歌唱，结果只能是——机器摇摇欲坠，最后爆发一场惊心动魄的性能暴走！
四、破局三连击：自定义线程池参数、消息分批与限流、资源隔离方案
自定义线程池参数 拒绝使用系统默认配置。根据实际业务压力测试结果，设置合理的核心线程数、最大线程数和队列容量。记住，队列容量不是越大越好。
@Configuration
public class RocketMQConfig {
@Bean("rocketMQAsyncExecutor")
public Executor rocketMQAsyncExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
// 🎯 关键配置
executor.setCorePoolSize(8); // 适当增加核心线程数
executor.setMaxPoolSize(16); // 设置最大线程数
executor.setQueueCapacity(1000); // 🔥 大幅降低队列容量
executor.setKeepAliveSeconds(60);
executor.setThreadNamePrefix("RocketMQ-Async-");
// 🚨 拒绝策略：当队列满时直接抛异常，而不是默默积累
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
executor.initialize();
return executor;
}
}
理解业务场景是配置基础。高频低延迟场景适合小队列+多线程；批量处理场景适合大队列+少线程。
消息分批与限流
@Service
public class SmartMessageSender {
private final Semaphore sendSemaphore = new Semaphore(100); // 限制并发发送数
public void sendBatchMessages(List<Message> messages) {
// 分批处理，避免单次消息过大
Lists.partition(messages, 50).forEach(batch -> {
try {
sendSemaphore.acquire(); // 获取发送许可
asyncSendWithBackpressure(batch);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
private void asyncSendWithBackpressure(List<Message> batch) {
CompletableFuture.supplyAsync(() -> {
try {
return rocketMQTemplate.syncSend("topic", batch); // 🔄 关键时刻用同步
} finally {
sendSemaphore.release(); // 释放许可
}
}, rocketMQAsyncExecutor);
}
}
资源隔离方案 生产者和消费者必须物理隔离。不要幻想同一组节点既能扛住生产压力又能消化消费压力。微服务架构下，自产自销模式往往导致资源死锁。
五、性能优化秘籍：自产自消的正确姿势、消息体优化
秘籍 1: 自产自消的正确姿势
// ❌ 错误：在同一个 JVM 进程中疯狂自产自消
@Component
public class BadProducerConsumer {
@Scheduled(fixedRate = 100)
public void produceMessages() {
// 疯狂生产消息
for (int i = 0; i < 1000; i++) {
rocketMQTemplate.asyncSend("topic", createLargeMessage());
}
}
@RocketMQMessageListener(topic = "topic")
public void consumeMessages(Message message) {
// 疯狂消费消息，与生产者竞争资源
heavyProcessing(message);
}
}
// ✅ 正确：合理的资源隔离
@Configuration
public class SmartResourceIsolation {
@Bean("producerExecutor")
public Executor producerExecutor() {
return createExecutor("Producer", 4, 8);
}
@Bean("consumerExecutor")
public Executor consumerExecutor() {
return createExecutor("Consumer", 8, 16);
}
}
秘籍 2: 消息体优化
// ❌ 直接发送大对象
BigObject bigObject = createBigObject(); // 可能几MB
rocketMQTemplate.asyncSend("topic", bigObject);
// ✅ 消息体瘦身
MessageRef messageRef = MessageRef.builder()
.id(bigObject.getId())
.storageKey(objectStorage.store(bigObject)) // 存储到外部存储
.build();
rocketMQTemplate.asyncSend("topic", messageRef);
六、 实战检查清单
在你的项目中，快速检查这些要点：
- 线程池配置: 是否自定义了异步发送的线程池？
- 队列容量: 任务队列是否设置了合理的上限？
- 消息大小: 单个消息体是否控制在合理范围内？
- 资源隔离: 生产者和消费者是否做了资源隔离？
- 监控告警: 是否配置了 GC、队列积压等关键指标监控？
- 压力测试: 是否在类生产环境下进行了充分的压测？
七、引导与警示：知其然，更要知其所以然
极客们，我们常常依赖那些“看似完美”的公共组件 API，殊不知在默认配置背后隐藏着无数陷阱。记住：使用公共组件 API，一定要知其然，知其所以然！ 谨慎配置线程池、自定义参数、按需调整任务队列长度。就像调试一台跑车，绝对不能让它在赛道上不停刹车进行 FullGC！
八、写在最后
自产自销架构看似简单，实则要面对生产者消费者资源博弈的复杂性问题。当吞吐量超过临界点时，系统行为会非线性恶化。
公共组件的默认配置永远是最保守选择。在云原生环境下，默认值往往成为性能反模式。线程池参数、连接池大小、超时时间这些基础配置，必须作为关键决策点写入技术方案评审清单。
作为工程师，我们不仅要会用轮子，更要理解轮子的运作机制。
记住：在分布式系统的世界里，没有银弹，只有权衡。
如果这篇文章拯救了你的服务器，请给个 👍
如果你也有类似的踩坑经历，欢迎在评论区分享你的血泪史！
Tags: #RocketMQ #FullGC #微服务 #性能优化 #踩坑记录
