chunk size直接决定事务边界、内存占用、失败恢复粒度和数据库压力，需结合业务语义、数据量、一致性要求及数据库承载能力权衡；默认commit-interval=10，推荐范围10–200，过大易致长事务与锁表，过小则事务开销剧增、i/o频繁。

Spring Batch 的 chunk 块大小直接决定事务边界、内存占用、失败恢复粒度和数据库压力。配置不是“越大越好”或“越小越安全”，而是要结合业务语义、数据量、一致性要求和数据库承载能力来权衡。

chunk size 决定事务提交频率和失败恢复点

chunk size 是 Step 中单次事务处理的记录数。它控制：

• 每读取、处理、写入多少条数据后提交一次事务
• 作业失败时，能从哪个位置恢复（例如 chunk=100，第 352 条失败，则下次从第 301 条开始）
• 内存中缓存的待处理数据量（越大越占内存）

默认 commit-interval=10，推荐范围是 10–200。超大值（如 1000+）易引发长事务、锁表、回滚日志膨胀；过小值（如 1 或 5）则事务开销剧增，I/O 频繁，吞吐下降。

按场景选 chunk size：强一致性 vs 高吞吐

不同业务对“失败后能否重试同一条数据”有不同容忍度：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 需要每条独立提交、不可回滚（如支付状态更新、通知发送）：设 chunk(1)。此时每个 item 单独事务，成功即落库，后续失败不影响已处理项
• 允许小批量原子性（如报表数据导入、日志归档）：chunk(50)～chunk(100)，兼顾效率与可控性
• 大批量 ETL 且数据库性能强（如千万级历史数据迁移）：可尝试 chunk(200)，但需配合数据库连接超时、事务隔离级别调优

chunk 与 pageSize 要区分配置

二者常被混淆，但职责不同：

• chunkSize（通过 .chunk(n) 设置）：控制事务和内存批次，影响 Writer 和整体流程
• pageSize（在 JdbcPagingItemReader / JpaPagingItemReader 中用 setPageSize(n)）：仅控制 Reader 每次查多少行，不影响事务

例如：pageSize=50 + chunkSize=10 表示 Reader 每次查 50 行缓存在内存，但 Spring Batch 只取前 10 行组成一个 chunk 处理并提交；剩余 40 行留待下个 chunk 使用。二者可不等，但 chunkSize ≤ pageSize 更合理，避免 Reader 频繁查询。

事务行为需配套调整

仅改 chunk size 不足以保障健壮性，还需明确异常策略：

• 默认 RuntimeException 触发当前 chunk 回滚；若想跳过脏数据而非中断，加 .skipPolicy(skipPolicy())
• 若某类异常（如业务校验失败）不应导致回滚，用 .noRollback(Exception.class)
• 使用 restartable(true) 确保 Job 失败后能基于 ExecutionContext 恢复，这是 chunk 机制发挥价值的前提

注意：JDBC 写入推荐用 JdbcBatchItemWriter（批量 insert/update）；若需每条走自定义逻辑（如混合 insert+update），chunk(1) 配合 RepositoryItemWriter 更清晰。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南