上周三下午三点，运维群里突然炸了——批量导出任务又把内存吃满了，Pod被OOM Killer干掉，重启了三次还是挂。老板在群里@我："这个导出功能上周不是刚优化过吗？怎么又挂了？"我打开监控一看，堆内存使用率从平时的40%飙到95%，GC停顿时间超过8秒。那天晚上折腾到凌晨一点，把整个批量处理链路从读取到写入全部重构了一遍。这篇记录下整个排查和优化过程。

## 一、先搞清楚：为什么十万条数据就OOM了

这批数据其实不算大，十万条记录、每条约2KB，总量才200MB左右。但问题出在处理方式上——代码里用的是一次性把所有数据加载到内存，然后逐条处理，最后一次性写入数据库。

```txt
// 原始代码：一次性加载
List<Record> records = mapper.selectAll(); // 十万条全进内存
for (Record r : records) {
    process(r); // 处理逻辑
}
mapper.batchInsert(records); // 一次性写入
```

这段代码的问题在于：
1. selectAll()把十万条记录全部加载到堆内存，约200MB
2. process()中每条记录又创建了新的对象，内存翻倍
3. batchInsert()一次性提交十万条SQL，数据库连接池被占满
4. GC无法回收，因为records列表一直持有引用

更隐蔽的问题是MyBatis的默认行为——selectAll()返回的List会持有所有对象的引用，直到方法结束才释放。如果方法执行时间长（比如处理十万条需要5分钟），这段时间内内存一直被占用。

## 二、第一步：流式读取，不让数据全进内存

解决OOM的第一步是改变读取方式——不要一次性加载所有数据，而是用游标逐条读取。MyBatis提供了Cursor接口，可以逐条返回数据，而不是一次性加载到List。

```txt
// 流式读取配置
@Select("SELECT * FROM large_table WHERE status = 0")
Cursor<Record> selectStream();

// 使用try-with-resources确保游标关闭
try (Cursor<Record> cursor = mapper.selectStream()) {
    for (Record r : cursor) {
        process(r);
    }
}
```

Cursor的工作原理是：
1. 数据库端保持游标打开，逐条返回数据
2. 应用端每次只从游标取一条，处理完再取下一条
3. 已处理的记录可以被GC回收，因为没有List持有引用

踩坑提醒：
- Cursor必须在try-with-resources中使用，否则游标不会关闭，数据库连接会泄漏
- MySQL的JDBC驱动默认会把所有结果加载到内存，需要加useCursorFetch=true和defaultFetchSize参数
- 流式读取时数据库连接会被长时间占用，需要评估连接池大小

## 三、第二步：背压控制，防止处理速度跟不上读取速度

流式读取解决了读取端的内存问题，但如果处理速度慢，数据还是会在内存中堆积。比如读取速度是1000条/秒，但处理速度只有100条/秒，那么每秒会有900条数据在内存中等待处理。

这时候需要背压控制——当处理队列满了，就暂停读取，等处理完再继续读取。

```txt
// 背压控制：有界队列
BlockingQueue<Record> queue = new ArrayBlockingQueue<>(1000);

// 读取线程
new Thread(() -> {
    try (Cursor<Record> cursor = mapper.selectStream()) {
        for (Record r : cursor) {
            queue.put(r); // 队列满时阻塞，自动背压
        }
    }
}).start();

// 处理线程
Record r;
while ((r = queue.poll(5, TimeUnit.SECONDS)) != null) {
    process(r);
}
```

ArrayBlockingQueue的put()方法在队列满时会自动阻塞，这就是天然的背压控制。队列大小设为1000，意味着内存中最多只有1000条待处理记录，约2MB，完全可控。

踩坑提醒：
- 队列大小要根据处理速度和内存预算来定，不是越大越好
- 读取线程和处理线程要分开，否则背压控制没有意义
- 处理线程要用poll(timeout)而不是take()，否则无法优雅停止
- 要处理中断异常，确保线程能正常退出

## 四、第三步：分批提交，不让数据库压力过大

读取和处理的内存问题解决了，但写入端还有问题——如果每条记录都单独提交一次SQL，数据库压力会很大；如果一次性提交所有记录，又会回到OOM问题。

正确的做法是分批提交——每处理N条记录就提交一次，然后清空缓冲区，继续处理下一批。

```txt
// 分批提交
int batchSize = 500;
List<Record> buffer = new ArrayList<>(batchSize);
int count = 0;

try (Cursor<Record> cursor = mapper.selectStream()) {
    for (Record r : cursor) {
        process(r);
        buffer.add(r);
        count++;
        
        if (buffer.size() >= batchSize) {
            mapper.batchInsert(buffer);
            buffer.clear(); // 清空缓冲区，释放内存
        }
    }
    // 处理最后一批
    if (!buffer.isEmpty()) {
        mapper.batchInsert(buffer);
    }
}
```

batchSize设为500是一个经验值：
- 太小（如10）：SQL提交次数多，数据库压力大
- 太大（如10000）：单次SQL太长，数据库解析慢，而且缓冲区占用内存多
- 500是一个平衡点，单次SQL约1MB，提交频率适中

踩坑提醒：
- batchInsert要用JDBC的addBatch()+executeBatch()，不要用循环单条insert
- 要在事务中执行分批提交，避免部分成功部分失败
- 最后一批不要忘记提交
- buffer.clear()很重要，否则已提交的记录不会被GC回收

## 五、踩坑清单：5个我实际踩过的坑

1. **MySQL JDBC默认不流式**：必须在连接URL加useCursorFetch=true，并且Statement.setFetchSize(Integer.MIN_VALUE)，否则还是一次性加载。我第一次忘了加这个参数，结果还是OOM。

2. **Cursor没关闭导致连接泄漏**：Cursor必须在try-with-resources中使用。我早期代码忘了关闭Cursor，结果数据库连接池被占满，后续请求全部超时。

3. **背压队列太大等于没控制**：我一开始把队列大小设为10000，结果内存还是涨到80%。后来改成1000，内存稳定在40%左右。队列大小要根据单条记录大小和内存预算来算。

4. **分批提交忘了事务**：第一批提交成功，第二批失败，导致数据不一致。后来加了@Transactional注解，要么全部成功，要么全部回滚。

5. **处理逻辑里又创建了大对象**：process()方法里我一开始用了字符串拼接，每条记录创建了几十个String对象。后来改成StringBuilder，内存占用降了30%。处理逻辑本身也要注意内存效率。

这次批量处理优化是在固乔快递批量查询助手的后端服务上做的，我主要负责读取链路的流式改造和分批提交逻辑，上线后批量任务的内存峰值从95%降到42%，处理速度从2小时降到25分钟，再也没有出现过OOM。

## 复盘要点

1. 流式读取是解决批量OOM的第一步：用MyBatis Cursor+MySQL useCursorFetch，逐条读取不占内存。
2. 背压控制防止处理速度跟不上读取速度：ArrayBlockingQueue有界队列，put()天然阻塞，队列大小按内存预算算。
3. 分批提交平衡数据库压力和内存：batchSize=500是经验值，用JDBC addBatch+executeBatch，别忘了事务和最后一批。

以上是个人实践记录，各平台具体功能以官方实时信息为准。

留个问题：你们线上批量任务的背压控制是用有界队列还是用信号量？分批大小是固定值还是动态调整？

上周三下午三点，运维群里突然炸了——批量导出任务又把内存吃满了，Pod被OOM Killer干掉，重启了三次还是挂。老板在群里@我："这个导出功能上周不是刚优化过吗？怎么又挂了？"我打开监控一看，堆内存使用率从平时的40%飙到95%，GC停顿时间超过8秒。那天晚上折腾到凌晨一点，把整个批量处理链路从读取到写入全部重构了一遍。这篇记录下整个排查和优化过程。

批量处理十万条数据OOM排查：流式读取、背压控制与分批提交的落地记录

记录批量处理十万条数据OOM排查全过程：原始代码一次性加载全量数据导致堆内存飙到95%，用MyBatis Cursor流式读取逐条加载，ArrayBlockingQueue有界队列做背压控制防止处理堆积，分批提交每500条一次平衡数据库压力。踩过MySQL JDBC默认不流式、Cursor未关闭连接泄漏、队列太大、忘加事务等5个坑。内存峰值从95%降到42%。

编程语言

数据库

后端

批量导出任务OOM根因是MyBatis一次性加载全部数据且未释放引用，通过Cursor流式读取、ArrayBlockingQueue背压控制（队列1000）、JDBC分批提交（batchSize=500）三项改造，内存峰值从95%降至42%，处理耗时从2小时缩短至25分钟，附5个实际踩坑点及事务处理注意事项。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

批量处理十万条数据OOM排查：流式读取、背压控制与分批提交的落地记录-腾讯云开发者社区-腾讯云

批量处理十万条数据OOM排查：流式读取、背压控制与分批提交的落地记录

批量处理十万条数据OOM排查：流式读取、背压控制与分批提交的落地记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐