Spring Batch实战：Chunk机制、断点续跑与生产级调优

1. 项目概述：为什么一个“Spring Batch Example”值得你花20分钟认真读完

我带过三届校招新人，也帮五家中小公司做过技术选型评审，每次聊到数据批处理，总有人脱口而出：“不就是for循环读数据库、改完再写回去吗？”——这话在单机跑几百条记录时确实成立。但当你的日志表每天新增800万行、订单对账需要比对37个异构系统、或者凌晨两点触发的风控模型训练任务突然卡在第12万条数据上时，“for循环”就成了生产事故的邀请函。而Spring Batch，就是Java生态里专治这类“数据洪流”的手术刀。它不是简单的工具库，而是一套经过金融、电商、电信等高并发场景十年锤炼的批处理生命周期管理体系。你看到的“Example”，背后是Chunk模式的事务分片机制、Step级别的重启恢复能力、JobRepository的元数据持久化设计，以及和Spring Boot天然融合的自动配置哲学。最近我在给一家物流SaaS做运单轨迹补全优化时，把原来耗时47分钟的单线程脚本，用Spring Batch重构后压到6分12秒，且失败后能从断点续跑——这背后不是魔法，而是对ItemReader/ItemProcessor/ItemWriter三件套的精准拿捏。本文不讲概念堆砌，只拆解一个真实可运行的Minimal Viable Example：从零初始化Maven工程，到跑通带数据库写入、异常重试、进度监控的完整链路。所有代码基于Spring Boot 3.2 + Spring Batch 5.0（当前最新稳定版），避开了网上90%教程还在用的XML配置和过时的JobBuilderFactory写法。如果你正被定时任务卡顿、数据一致性焦虑、或面试官突然问“Batch怎么保证失败不丢数据”这些问题困扰，这篇就是为你写的实操手册。

2. 核心架构解析：Spring Batch不是“批处理框架”，而是“批处理操作系统”

2.1 为什么必须抛弃“for循环思维”：从三个真实故障说起

先说三个我亲历的线上事故，它们共同指向同一个认知盲区：把批处理当成单机脚本。第一个是某电商平台的会员等级计算任务，原逻辑是查出所有VIP用户ID列表（约230万条），for循环调用积分服务接口。结果某天积分服务响应时间从50ms飙升到800ms，整个任务卡在第18万条，持续占用JVM堆内存，最终OOM导致应用假死。第二个是银行对账系统，用单SQLUPDATE ... WHERE id IN (SELECT id FROM temp_table)更新百万级账户余额，锁表时间超12分钟，业务交易全部阻塞。第三个更典型：某IoT平台的设备固件升级状态同步，开发者用List<Device>一次性加载所有待升级设备（峰值达412万条），GC频繁触发，Full GC间隔缩短到90秒，系统进入“GC风暴”。这些都不是代码bug，而是架构性误判——把批处理当成了“大号单次操作”。Spring Batch的底层设计哲学，恰恰是反其道而行之：它强制你把“大任务”切成可控的“小块”（Chunk），每个小块独立事务、独立内存、独立错误处理。就像快递分拣中心不会让一辆车送完全国包裹，而是按区域分装、按邮编分拣、按楼栋投递。这种设计带来三个硬性保障：第一，内存可控——Chunk size设为1000，就永远不会加载超过1000条记录到内存；第二，失败隔离——第5个Chunk失败，不影响前4个已提交的结果；第三，断点续跑——JobRepository会持久化每个Step的执行状态，重启后自动跳过已完成Chunk。这不是功能亮点，而是生存底线。

2.2 Spring Batch五大核心组件的物理意义

很多教程把Reader/Processor/Writer画成流水线图，但没说清它们在JVM里的真实存在形态。我用一个实际线程栈帮你建立体感：当你启动Job时，Spring Batch会创建一个SimpleAsyncTaskExecutor（默认单线程），这个线程会反复执行ChunkOrientedTasklet的doExecute()方法。而这个方法内部，本质是三段式循环：

// 伪代码，体现Chunk执行的真实流程 while (chunkContext.isComplete() == false) { // 1. Reader：从数据源拉取一批（size=1000） List<Item> items = reader.read(); // 可能是JdbcCursorItemReader，底层用ResultSet.next() // 2. Processor：逐条转换（注意：这里是for循环，但数据量已被Chunk限制） List<Item> processedItems = new ArrayList<>(); for (Item item : items) { Item processed = processor.process(item); // 可能调用外部HTTP服务 if (processed != null) processedItems.add(processed); } // 3. Writer：批量写入（JdbcBatchItemWriter会调用JdbcTemplate.batchUpdate） writer.write(processedItems); // 底层是PreparedStatement.addBatch() }

关键点在于：Reader决定数据源切片方式，Processor决定单条处理逻辑，Writer决定落地策略，而ChunkManager控制整体节奏。比如JdbcPagingItemReader用ORDER BY id LIMIT 1000 OFFSET 0分页，JdbcCursorItemReader用游标避免重复扫描，FlatFileItemReader按行解析CSV。Processor可以是纯内存计算，也可以是FeignClient调用，但必须保证幂等性——因为Spring Batch的重试机制可能让同一条数据被process两次。Writer的JdbcBatchItemWriter会把1000条数据组装成一条INSERT INTO ... VALUES (...),(...),...语句，比单条INSERT快17倍（实测MySQL 8.0）。而CompositeItemWriter则允许你同时写数据库和发Kafka消息，满足审计日志双写需求。这些不是抽象接口，而是有明确内存占用、线程模型、SQL生成行为的具体实现。

2.3 Job与Step的生命周期：为什么重启后能“记住自己在哪”

很多人困惑：Job重启时，Batch怎么知道该从哪继续？答案藏在JobRepository里。默认情况下，Spring Batch用HSQLDB内存库，但生产环境必须换成MySQL/PostgreSQL。它的核心表只有三张：BATCH_JOB_INSTANCE（记录Job定义，如jobName+params的MD5）、BATCH_JOB_EXECUTION（记录每次执行，含开始/结束时间、状态）、BATCH_STEP_EXECUTION（记录每个Step的详细状态，最关键的是READ_COUNT、WRITE_COUNT、COMMIT_COUNT、EXIT_CODE）。当Chunk执行失败时，StepExecution的EXIT_CODE会被设为FAILED，READ_COUNT存的是已成功读取的记录数。重启Job时，JobOperator.restart()会查询BATCH_STEP_EXECUTION，找到最后失败的Step，然后调用JdbcPagingItemReader.setPage()或JdbcCursorItemReader.setCurrentItemCount()，把游标定位到READ_COUNT位置。这就是“断点续跑”的物理实现——没有黑科技，就是数据库里存了几个数字。所以，如果你发现重启后从头开始，第一反应不是框架bug，而是检查JobRepository是否配置正确，或者JobLauncher是否用了SimpleJobLauncher（它不支持重启）。

3. 实战搭建：从零开始构建一个可监控、可重试、可审计的Batch作业

3.1 Maven依赖与Spring Boot配置：避开三个致命陷阱

新建Spring Boot 3.2项目时，第一个坑是依赖版本冲突。网上大量教程用spring-boot-starter-batch2.x，但Spring Boot 3.x要求Jakarta EE 9+命名空间，必须用spring-boot-starter-batch3.2.x。我的pom.xml核心依赖如下：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-batch</artifactId> <!-- Spring Boot 3.2.x 自动引入 spring-batch-core 5.0.x --> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- 生产环境必须添加监控 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>

关键陷阱一：别用HSQLDB做生产JobRepository。spring-boot-starter-batch默认启用DataSource自动配置，但若你没配spring.datasource.url，它会悄悄创建HSQLDB内存库，重启即丢失所有执行记录。必须在application.yml中显式配置：

spring: datasource: url: jdbc:mysql://localhost:3306/batch_db?serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver batch: jdbc: initialize-schema: always # 首次启动自动建表，生产环境改为never

关键陷阱二：禁用默认Job自动执行。Spring Boot 2.x默认启动时运行所有@Bean Job，3.x改为spring.batch.job.enabled=false。否则应用一启动就跑Job，调试时会疯掉。正确配置：

spring: batch: job: enabled: false # 必须关闭！通过API手动触发

关键陷阱三：Actuator端点要开放。想看Job执行状态，必须暴露/actuator/batch端点：

management: endpoints: web: exposure: include: health,info,batch,metrics,loggers endpoint: batch: show-details: ALWAYS

这样配置后，启动应用访问http://localhost:8080/actuator/batch，就能看到所有Job定义和执行历史。这是生产环境监控的生命线。

3.2 数据模型与测试数据：用真实业务场景驱动开发

我们模拟一个电商场景：每天凌晨同步用户订单数据到数据仓库。源表orders_source有10万条测试数据，目标表orders_warehouse需清洗后写入。建表SQL如下：

-- 源数据表（模拟业务库） CREATE TABLE orders_source ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(50) NOT NULL, amount DECIMAL(10,2) NOT NULL, status VARCHAR(20) DEFAULT 'PAID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 目标数据仓库表（字段更规范，增加ETL时间戳） CREATE TABLE orders_warehouse ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id VARCHAR(50) NOT NULL, -- 来源id转字符串 user_key VARCHAR(50) NOT NULL, -- 用户标识标准化 final_amount DECIMAL(12,2) NOT NULL, order_status ENUM('SUCCESS','FAILED','PENDING') DEFAULT 'SUCCESS', etl_timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_key (user_key), INDEX idx_etl_time (etl_timestamp) );

插入10万条测试数据（用存储过程或Python脚本，这里省略）。重点在于：orders_source.status是字符串'PAID'/'SHIPPED'，而orders_warehouse.order_status是枚举，这迫使Processor必须做状态映射——这才是真实业务的复杂性。

3.3 Reader/Processor/Writer三件套编码：每行代码都有业务含义

3.3.1 ItemReader：用JdbcPagingItemReader实现高效分页

@Bean public JdbcPagingItemReader<OrderSource> orderSourceReader(DataSource dataSource) { JdbcPagingItemReader<OrderSource> reader = new JdbcPagingItemReader<>(); reader.setDataSource(dataSource); reader.setFetchSize(1000); // 每次从DB拉1000条，匹配Chunk size // 分页查询：必须有ORDER BY，否则分页不可靠 MySqlPagingQueryProvider queryProvider = new MySqlPagingQueryProvider(); queryProvider.setSelectClause("id, user_id, amount, status, create_time"); queryProvider.setFromClause("from orders_source"); queryProvider.setWhereClause("status = 'PAID'"); // 只同步已支付订单 queryProvider.setSortKeys(Collections.singletonMap("id", Order.ASCENDING)); reader.setQueryProvider(queryProvider); reader.setRowMapper(new BeanPropertyRowMapper<>(OrderSource.class)); return reader; }

为什么用JdbcPagingItemReader而不是JdbcCursorItemReader？因为前者用LIMIT/OFFSET，适合大数据量分页；后者用JDBC游标，在MySQL中可能锁表。setFetchSize(1000)告诉JDBC驱动一次取1000行，减少网络往返。WHERE status = 'PAID'是业务过滤逻辑，不是性能优化——它减少了Reader输出的数据量，从而降低Processor和Writer压力。

3.3.2 ItemProcessor：状态转换与数据清洗的战场

@Component public class OrderProcessor implements ItemProcessor<OrderSource, OrderWarehouse> { @Override public OrderWarehouse process(OrderSource source) throws Exception { // 业务规则1：金额大于10000的订单，标记为高价值 BigDecimal finalAmount = source.getAmount(); if (source.getAmount().compareTo(new BigDecimal("10000")) > 0) { finalAmount = source.getAmount().multiply(new BigDecimal("0.95")); // 打95折 } // 业务规则2：状态映射（真实场景可能调用风控服务） String warehouseStatus = "SUCCESS"; switch (source.getStatus()) { case "PAID": warehouseStatus = "SUCCESS"; break; case "SHIPPED": warehouseStatus = "SUCCESS"; break; case "CANCELLED": warehouseStatus = "FAILED"; break; default: warehouseStatus = "PENDING"; } // 构建目标对象 OrderWarehouse warehouse = new OrderWarehouse(); warehouse.setOrderId(String.valueOf(source.getId())); warehouse.setUserKey("U_" + source.getUserId()); // 用户ID标准化 warehouse.setFinalAmount(finalAmount); warehouse.setOrderStatus(warehouseStatus); return warehouse; } }

Processor的核心原则：无副作用、幂等、轻量。这里做了两件事：金额调整（业务规则）和状态映射（数据清洗）。注意String.valueOf(source.getId())——源表id是BIGINT，目标表order_id是VARCHAR，这是典型的类型适配。如果Processor里调用FeignClient，必须加@RetryableTopic注解并配置重试策略，否则网络抖动会导致整个Chunk失败。

3.3.3 ItemWriter：批量写入与错误处理

@Bean public JdbcBatchItemWriter<OrderWarehouse> orderWarehouseWriter(DataSource dataSource) { JdbcBatchItemWriter<OrderWarehouse> writer = new JdbcBatchItemWriter<>(); writer.setDataSource(dataSource); writer.setSql("INSERT INTO orders_warehouse " + "(order_id, user_key, final_amount, order_status, etl_timestamp) " + "VALUES (:orderId, :userKey, :finalAmount, :orderStatus, NOW())"); // 使用BeanPropertyItemSqlParameterSource来自动映射属性 writer.setItemSqlParameterSourceProvider(new BeanPropertyItemSqlParameterSourceProvider<>()); // 关键：设置异常分类器，让特定异常不导致Chunk失败 writer.setExceptionClassifier(new CustomSQLExceptionClassifier()); return writer; } // 自定义异常分类器：主键冲突时跳过，不中断Chunk public class CustomSQLExceptionClassifier extends SQLExceptionClassifier { public CustomSQLExceptionClassifier() { setDefaultClassification(new RuntimeException("Unknown SQL error")); // MySQL主键冲突错误码1062，归类为非致命错误 addClassification("1062", new NonTransientResourceException("Duplicate key")); } }

Writer的setSql()用命名参数:orderId，比位置参数?更安全。BeanPropertyItemSqlParameterSourceProvider自动把OrderWarehouse的getter方法名转为SQL参数名。最关键是ExceptionClassifier——它让Batch知道：主键冲突（1062错误）是业务可接受的，跳过这条数据继续写；而连接超时则是致命错误，必须回滚整个Chunk。这比try-catch优雅得多。

3.4 Job配置：Chunk机制与重试策略的黄金组合

@Bean public Job syncOrdersJob(JobRepository jobRepository, JobCompletionNotificationListener listener, Step syncOrdersStep) { return new JobBuilder("syncOrdersJob", jobRepository) .listener(listener) // 监听Job完成事件 .flow(syncOrdersStep) .end() .build(); } @Bean public Step syncOrdersStep(JobRepository jobRepository, PlatformTransactionManager transactionManager, JdbcPagingItemReader<OrderSource> reader, OrderProcessor processor, JdbcBatchItemWriter<OrderWarehouse> writer) { return new StepBuilder("syncOrdersStep", jobRepository) .<OrderSource, OrderWarehouse>chunk(1000, transactionManager) // Chunk size=1000 .reader(reader) .processor(processor) .writer(writer) .faultTolerant() // 启用容错 .skip(Exception.class) // 跳过所有异常 .skipLimit(10) // 最多跳过10条 .retry(ConnectException.class) // 网络异常重试 .retryLimit(3) // 最多重试3次 .retryPolicy(new SimpleRetryPolicy(3, Collections.singletonMap(ConnectException.class, true))) .build(); }

Chunk size设为1000是经验值：太小（如10）导致事务开销大，太小（如10000）内存占用高。faultTolerant()开启容错后，.skip()和.retry()才能生效。这里配置了双重保护：对所有异常跳过（最多10条），对ConnectException重试（最多3次）。重试策略用SimpleRetryPolicy，明确指定只对网络异常重试——因为数据库唯一键冲突重试毫无意义。JobCompletionNotificationListener是自定义监听器，Job完成后发企业微信告警，代码略。

4. 进阶实战：监控、调优与生产级问题排查

4.1 Actuator监控端点详解：读懂Batch的健康心跳

启动应用后，访问http://localhost:8080/actuator/batch，返回JSON结构如下：

{ "jobs": [ { "name": "syncOrdersJob", "instances": [ { "id": 1, "execution": { "id": 1, "status": "COMPLETED", "startTime": "2023-10-05T02:15:22.123", "endTime": "2023-10-05T02:16:45.678", "readCount": 100000, "writeCount": 100000, "commitCount": 100, "rollbackCount": 0, "exitCode": "COMPLETED" } } ] } ] }

关键指标解读：

• readCount/writeCount：验证数据完整性，二者必须相等（除非Processor过滤了数据）
• commitCount：等于readCount / chunkSize，这里100000/1000=100，证明Chunk机制生效
• rollbackCount：非零值说明有Chunk因异常回滚，需查日志
• exitCode：COMPLETED是理想状态，FAILED需结合failureExceptions字段分析

更细粒度的监控在/actuator/metrics端点，搜索spring.batch.job.execution.time，可看到Job执行时间的P95/P99分位值。我把这个指标接入Prometheus，当P95>300秒时自动告警——这比单纯看“成功/失败”更有业务价值。

4.2 性能调优四步法：从6分钟到90秒的实录

在我优化物流订单同步Job时，初始版本耗时6分23秒。按以下步骤逐步优化：

第一步：定位瓶颈（Arthas诊断）
用Arthastrace命令跟踪JdbcPagingItemReader.read()，发现ResultSet.next()平均耗时42ms，远高于预期。原因：orders_source表缺少status字段索引。加索引后，Reader耗时从3分12秒降到48秒。

第二步：调整Chunk size
原Chunk size=100，commitCount=1000，事务开销大。改为1000后，commitCount=100，Writer批量写入效率提升。但Chunk size不能无限增大——当设为5000时，单次read()内存占用超200MB，GC压力剧增。最终选定2000，平衡内存与IO。

第三步：启用并行Step（谨慎使用）
对独立数据源可并行处理。例如把订单按user_id % 4分4个Step，每个Step处理不同用户段。但要注意：并行Step不能共享同一Writer，否则数据竞争。我们改用PartitionStep，主Step负责分片，4个Slave Step各写不同表分区。

第四步：数据库连接池调优
HikariCP默认maximumPoolSize=10，但并行Step需要更多连接。设为maximumPoolSize=20，并增加connection-timeout=30000。最终耗时压到1分32秒，提升4.2倍。

4.3 生产环境十大高频问题与根因分析

4.4 安全加固与合规实践：金融级Batch的必备清单

在银行项目中，客户要求Batch作业满足等保三级。我们做了五项加固：

1. 敏感数据脱敏：Processor中对user_id做SHA256哈希，而非明文写入user_key；
2. SQL注入防护：Writer严格用命名参数，禁用字符串拼接SQL；
3. 执行权限最小化：数据库账号仅授予orders_sourceSELECT和orders_warehouseINSERT权限；
4. 审计日志留存：自定义JobExecutionListener，在afterJob()中记录JobInstance.getId()、JobExecution.getExitStatus()、StepExecution.getReadCount()到独立审计表；
5. 密码加密：application.yml中spring.datasource.password用Jasypt加密，启动时通过--jasypt.encryptor.password=xxx解密。

特别提醒：JdbcCursorItemReader在MySQL中默认不启用游标，必须在application.yml中显式配置：

spring: datasource: hikari: >