调整批处理大小是防止java应用内存溢出最直接有效的手段，核心是将大任务拆为小单元以利gc及时回收；需结合压测确定合理值，如数据库读取每批100–500条、批量写入50–200条，并配合资源释放与jvm参数优化。
调整批处理大小是防止 Java 应用在处理大量数据时发生内存溢出（OutOfMemoryError: Java heap space）最直接、最有效的手段之一。核心思路是：**不让单次操作加载/创建/持有过多对象，把大任务拆成可控的小单元，让 GC 能及时回收中间对象**。
为什么批处理过大会导致内存溢出
常见场景包括：从数据库查几万条记录一次性装进 List<entity></entity>；用 addAll() 批量插入集合；或在循环中不断 new 对象却未及时释放。这些操作会集中占用堆内存，尤其当对象较大（如含 byte[]、JSON 字符串）或生命周期被意外延长（如被静态 Map 缓存）时，极易撑爆堆空间。
合理设置批处理数量的关键原则
没有通用“最佳值”，需结合实际压测和监控来定。但可参考以下经验性指导：
-
数据库读取：JDBC 查询建议每批 100–500 条；MyBatis 的
fetchSize可设为 100～200，配合流式游标（ResultHandler或Cursor）避免全量加载 -
批量写入：JDBC
addBatch()/ MyBatis<foreach></foreach>建议每批 50–200 条；超过 500 容易触发 PreparedStatement 内存膨胀或事务日志过大 -
内存中分片处理：对已有大集合做分批遍历，推荐每批 1000～5000 元素（取决于单个对象大小）；可用 Guava 的
Lists.partition(list, batchSize)或 Java 8+ 的Stream.iterate+limit拆分 -
避免硬编码：将批大小设为可配置参数（如 Spring Boot 的
@Value("${batch.size:200}")），方便不同环境调优
配合 JVM 参数与代码习惯一起生效
仅调小批处理数还不够，必须同步保障内存能及时释放：
- 每批处理完后显式清空临时集合（
list.clear()或重新 new），尤其避免静态集合累积 - 使用
try-with-resources确保 ResultSet、InputStream 等资源及时关闭，防止关联对象无法回收 - 启动时添加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/dumps，便于复现时分析哪一批次引发溢出 - 堆大小仍需合理设定，例如
-Xms2g -Xmx2g（避免动态扩容开销），再配合批处理优化，效果更稳
一个安全的分批处理示例
以下是一个典型的数据库导出分页处理片段（非全量加载）：
（伪代码逻辑，强调结构而非语法细节）
int pageSize = 200;
int offset = 0;
boolean hasMore = true;
<p>while (hasMore) {
List<order> batch = orderMapper.selectByPage(offset, pageSize);
if (batch.isEmpty()) {
hasMore = false;
break;
}
processBatch(batch); // 处理本批次，不保留引用
batch.clear(); // 主动清空引用（可选，但明确）
offset += pageSize;
}</order></p>
注意：这里没用 SELECT * FROM table 全查，而是靠分页 SQL + 显式控制批次，内存占用始终在数百对象量级，大幅降低 OOM 风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
