4. Batch Size的权衡艺术：Size太大导致内存溢出，Size太小导致性能提升不明显，如何找到最佳Size

聊到Batch Size，我脑子里第一个蹦出来的画面，是几年前一次线上事故。

那天凌晨，系统突然报警，内存飙升，GC频繁到几乎卡死。我一看，好家伙，一个批处理任务把堆内存撑爆了。查下来原因很简单——Batch Size设成了100万，而单条数据就有2KB。你算算，200万KB，差不多2GB，能不炸吗？

从那以后，我对Batch Size的敬畏心就起来了。说白了，这个参数就像炒菜的火候——太大糊锅，太小不熟。今天咱们就聊聊，怎么找到那个“刚刚好”的Size。

4.1 为什么Batch Size这么难调？

先看一个最简单的场景：你要从数据库读100万条数据，然后批量写入另一个系统。

如果Size设成1，那就是逐条处理。每次都要建立连接、发送请求、等待响应。100万次网络开销，性能能好才怪。

如果Size设成100万，一次性全加载到内存。嗯，内存够大吗？GC扛得住吗？万一中间某条失败，整个批次回滚，代价你算过吗？

所以，Batch Size的本质，是在吞吐量和资源消耗之间找平衡点。我个人习惯把这个平衡点叫做“甜蜜点”（Sweet Spot）。

4.2 影响Batch Size的关键因素

你想想看，不同场景下，最佳Size能一样吗？显然不能。我总结了三个核心因素：

4.2.1 单条数据的大小

这个最直观。如果单条数据只有几十字节，那Size设个几千甚至上万都没问题。但如果单条数据是带图片的JSON，动辄几百KB，那Size就得保守点。

我记得有个项目，处理的是用户上传的日志文件，每条日志平均4KB。我们一开始把Size设成5000，结果内存直接飙到2GB。后来压到500，稳了。

单条数据大小	建议Batch Size范围	说明
≤ 100字节	5000 ~ 10000	网络开销是瓶颈，可以大胆设大
100字节 ~ 1KB	1000 ~ 5000	适中范围，需要压测验证
1KB ~ 10KB	200 ~ 1000	内存压力开始显现，保守点
≥ 10KB	50 ~ 200	建议配合分页或流式处理

4.2.2 下游系统的处理能力

你Batch再大，下游系统吞不下也是白搭。比如数据库的批量插入，MySQL的max_allowed_packet默认才4MB。你一个批次超过这个值，直接报错。

我曾经对接过一个第三方API，文档上说支持批量，但实际测下来，一次最多处理100条。超过100条，接口就返回500。嗯，这种坑踩过一次就记住了。

4.2.3 JVM堆内存与GC策略

如果你是Java应用，Batch Size还跟GC强相关。Size太大，年轻代放不下，直接晋升到老年代，触发Full GC。Full GC一多，系统响应时间就崩了。

我一般建议，Batch Size占用的内存不要超过堆内存的5%~10%。比如堆内存是4GB，那一个批次的数据量控制在200MB~400MB以内。

4.3 如何找到最佳Size？——实战方法论

理论说完了，来点干货。我自己的调优流程是这样的：

4.3.1 第一步：估算下限

下限由网络延迟决定。假设网络RTT是10ms，你希望批处理带来的延迟不超过总延迟的10%。那一个批次至少需要处理多少条？

简单算一下：如果单条处理耗时1ms，网络10ms，那单条总耗时11ms。批处理时，网络开销被摊薄，假设批次大小是N，那单条平均耗时 ≈ 处理时间 + 网络时间/N。我们希望这个值比单条处理快至少5倍。

嗯，公式有点绕。直接给结论：一般建议下限是50~100条，低于这个值，批处理的意义就不大了。

4.3.2 第二步：估算上限

上限由内存决定。先算单批次最大内存占用：

// 伪代码示例
int batchSize = 1000;
int singleRecordSize = 1024; // 1KB
double serializationOverhead = 1.5; // 序列化膨胀系数

long estimatedMemory = batchSize * singleRecordSize * serializationOverhead;
// 结果：1000 * 1024 * 1.5 ≈ 1.5MB

// 建议不超过堆内存的10%
long maxMemory = Runtime.getRuntime().maxMemory();
long safeLimit = (long)(maxMemory * 0.1);

if (estimatedMemory > safeLimit) {
    // 需要调小Batch Size
    batchSize = (int)(safeLimit / (singleRecordSize * serializationOverhead));
}

4.3.3 第三步：压测找甜蜜点

有了上下限，剩下的就是压测。我一般会取几个关键点：下限、上限、以及中间的几个值（比如上限的25%、50%、75%）。

压测时主要看两个指标：

• 吞吐量（TPS/QPS）：每秒能处理多少批次
• P99延迟：最慢的1%请求耗时

举个例子，我之前调优一个数据同步任务，结果是这样的：

Batch Size	吞吐量（条/秒）	P99延迟（ms）	GC暂停时间（ms）
100	8,000	45	5
500	35,000	62	12
1000	52,000	88	28
2000	58,000	150	85
5000	55,000	320	210

看到没？Size从1000到2000，吞吐量只提升了11%，但P99延迟涨了70%，GC暂停时间翻了3倍。这个项目的甜蜜点就是1000。

4.4 动态Batch Size——更高级的玩法

固定Size虽然简单，但不够灵活。流量有波峰波谷，系统负载也在变化。我最近在项目中尝试了动态Batch Size，效果不错。

核心思路：根据当前系统的内存使用率和下游响应时间，动态调整Size。

// 动态Batch Size的简化实现
public class DynamicBatchSizeAdjuster {
    private int minSize = 100;
    private int maxSize = 5000;
    private int currentSize = 1000;
    
    // 内存使用率阈值
    private double memoryThreshold = 0.7;
    // 下游响应时间阈值（毫秒）
    private long latencyThreshold = 100;
    
    public int getBatchSize(double memoryUsage, long avgLatency) {
        if (memoryUsage > memoryThreshold || avgLatency > latencyThreshold) {
            // 压力大，减小Size
            currentSize = Math.max(minSize, currentSize / 2);
        } else {
            // 压力小，尝试增大Size
            currentSize = Math.min(maxSize, currentSize * 2);
        }
        return currentSize;
    }
}

嗯，这个方案不是银弹。如果系统波动太大，频繁调整Size反而会引入抖动。我建议加上冷却时间，比如每次调整后至少稳定30秒再调下一次。

4.5 总结一下

Batch Size的权衡，说白了就是三个字：测、算、调。

• 测：压测出不同Size下的吞吐和延迟曲线
• 算：根据内存和网络估算上下限
• 调：结合业务场景，找到那个“不冒进、不保守”的甜蜜点

我个人习惯，每次上线前都会做一轮Batch Size的压测。哪怕只是改了个序列化方式，Size的甜蜜点都可能变。别偷懒，压一下，心里踏实。