1. 为什么这个整合示例值得你花30分钟认真读完Spring Boot整合Spring Batch——这八个字背后藏着Java后端工程师在真实业务场景中绕不开的硬核能力批量数据处理的稳定性、可监控性与工程化落地能力。我带过三支不同行业的后端团队从金融风控的数据清洗、电商订单的异步结算到医疗影像元数据的标准化入库所有日均处理量超50万条的离线任务最终都收敛到Spring Batch这个技术选型上。它不是“又一个框架”而是把“怎么安全地跑完一千万条记录”这件事从靠人盯、靠日志查、靠重启硬扛变成了可配置、可重试、可分片、可追踪的标准化流程。很多人第一次接触时以为只是写个JobStep就完事结果上线后遇到内存溢出、事务不回滚、失败任务无法恢复、进度无法监控等问题才意识到Spring Batch的真正门槛不在API调用而在对批处理本质的理解和对生产环境约束的敬畏。这篇文章不讲概念定义不堆API列表只聚焦一个真实可运行的示例——从零开始搭建一个带数据库存储、失败重试、分块提交、进度监控的订单导出Job并把我在三个项目中踩过的坑、调优的关键参数、必须写的监控钩子全部揉进代码和注释里。如果你正面临定时报表卡死、Excel导入超时、历史数据迁移失败率高这类问题或者准备Java中高级面试需要讲清楚“批量任务怎么设计”这篇就是为你写的实操手册。2. 整体架构设计与方案选型逻辑2.1 为什么是Spring Batch而不是手写线程池或Quartz先说结论Spring Batch不是“替代”线程池或定时任务而是为“有状态、需保障、要追溯”的批量作业提供基础设施层。我见过太多团队用ScheduledExecutorService硬扛数据迁移初期看着简单但很快暴露问题状态丢失服务重启后正在处理的第87246条记录没了只能全量重跑事务失控每100条commit一次但某次网络抖动导致部分commit成功、部分失败数据不一致监控真空只知道“任务在跑”但不知道已处理多少、卡在哪、失败原因是什么资源滥用单次读取10万条到内存再处理直接触发OutOfMemoryError: insufficient memory。Spring Batch通过JobRepository持久化执行状态、Chunk-oriented Processing分块处理事务边界、Retry/Recovery机制失败自动重试或跳过和Listener体系生命周期钩子四层设计把上述问题变成可配置项。比如ChunkSize1000意味着每处理1000条才提交一次事务RetryTemplate可配置重试3次且仅对SQLException生效JobExplorer能实时查出当前Job的执行ID、状态、已处理条数。这些不是“功能亮点”而是生产环境的生存底线。2.2 Spring Boot为何是最佳搭档Spring Boot对Spring Batch的封装核心价值在于消除XML配置和模板代码。传统Spring Batch需要写大量job.xml、step.xml还要手动配置DataSource、TransactionManager、JobRepository。Spring Boot Starter Batch把这些变成自动配置自动创建JobRepository基于DataSource自动注入JobLauncher、JobRegistryEnableBatchProcessing注解一键开启批处理支持application.properties中一行spring.batch.job.enabledfalse即可禁用默认启动Job。但要注意自动配置是双刃剑。比如默认的JobRepository使用HSQLDB内存数据库上线必须切换为MySQL/PostgreSQL默认JobLauncher是同步阻塞式高并发调度需替换为AsyncTaskExecutor。我在电商项目中就因没覆盖默认配置导致大促期间Job排队阻塞主线程最后加了Bean自定义JobLauncher才解决。所以整合不是“加依赖就完事”而是理解自动配置的边界明确哪些必须覆盖。2.3 示例场景选择订单导出Job的设计深意本示例选用“订单导出为CSV文件”作为核心场景原因有三业务普适性报表、对账、数据迁移等场景本质都是“读取→转换→输出”订单导出覆盖了ReaderJDBC读库、Processor格式转换、Writer文件写入全链路问题暴露充分导出过程涉及大表扫描性能、中文乱码编码、空值处理健壮性、磁盘满资源监控比单纯控制台打印更能检验整合质量调试友好CSV文件可直接打开验证比消息队列或数据库写入更易定位数据问题。具体设计如下Reader从order_info表读取statusSHIPPED的订单按create_time分页避免全表锁Processor将BigDecimal金额转为字符串、LocalDateTime转为yyyy-MM-dd HH:mm:ss、空字段补N/AWriter写入/tmp/export_orders_20241105.csv使用FlatFileItemWriter并配置LineAggregator生成CSV行关键增强添加SkipPolicy跳过解析失败的订单、CompletionPolicy控制每块处理100条、JobExecutionListener记录总耗时。这个设计刻意避开“读文件→写数据库”等简单路径因为真实业务中90%的批量任务都是“数据库→文件”或“文件→数据库”必须直面字符编码、大数据量分页、IO异常等硬骨头。3. 核心细节解析与实操要点3.1 依赖配置版本兼容性是第一道坎Spring Boot 3.x与Spring Batch 5.x的整合最大的坑是Jakarta EE命名空间迁移。Spring Boot 2.7用的是javax.*包而3.x全面升级为jakarta.*。如果错误引入旧版依赖编译会报ClassNotFoundException: javax.transaction.Transactional。正确配置如下Mavenparent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.0/version !-- 必须≥3.0.0 -- /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-batch/artifactId !-- 不用指定versionparent已定义 -- /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 关键Spring Batch 5.x要求Jakarta EE API -- dependency groupIdjakarta.transaction/groupId artifactIdjakarta.transaction-api/artifactId /dependency /dependencies提示若使用Oracle或PostgreSQL替换mysql-connector-java为对应驱动并在application.yml中修改spring.datasource.url。切记不要同时引入spring-boot-starter-data-jpa它会干扰Batch的事务管理器除非你明确需要JPA实体映射。3.2 数据库表初始化JobRepository的底层依赖Spring Batch必须有一套元数据表来存储Job执行状态如BATCH_JOB_INSTANCE、BATCH_STEP_EXECUTION。Spring Boot Starter Batch会自动执行建表脚本但前提是DataSource已配置且数据库用户有建表权限。建表SQL由spring-batch-core提供位于org/springframework/batch/core/schema-mysql.sqlMySQL等路径。实际部署时我建议手动执行建表而非依赖自动创建原因有二自动建表可能因权限不足失败且错误日志模糊只报Table batch_job_instance doesnt exist生产环境通常要求DBA审核DDL不能由应用直接建表。MySQL建表语句精简版完整版见官方GitHubCREATE TABLE BATCH_JOB_INSTANCE ( JOB_INSTANCE_ID BIGINT PRIMARY KEY, VERSION BIGINT, JOB_NAME VARCHAR(100) NOT NULL, JOB_KEY VARCHAR(32) NOT NULL, constraint JOB_INST_UN unique (JOB_NAME, JOB_KEY) ); CREATE TABLE BATCH_JOB_EXECUTION ( JOB_EXECUTION_ID BIGINT PRIMARY KEY, VERSION BIGINT, JOB_INSTANCE_ID BIGINT NOT NULL, CREATE_TIME DATETIME NOT NULL, START_TIME DATETIME DEFAULT NULL, END_TIME DATETIME DEFAULT NULL, STATUS VARCHAR(10), EXIT_CODE VARCHAR(2500), EXIT_MESSAGE VARCHAR(2500), LAST_UPDATED DATETIME, JOB_CONFIGURATION_LOCATION VARCHAR(2500) NULL, constraint JOB_INST_EXEC_FK foreign key (JOB_INSTANCE_ID) references BATCH_JOB_INSTANCE(JOB_INSTANCE_ID) ); -- 其余表BATCH_STEP_EXECUTION等同理...注意表名前缀默认为BATCH_可通过spring.batch.table-prefixBATCH_修改。若数据库区分大小写如Linux下MySQL确保表名全大写否则JobRepository查询失败。3.3 Job配置的核心陷阱EnableBatchProcessing的副作用EnableBatchProcessing是开启Spring Batch的入口注解但它会强制注册多个Bean其中两个极易引发问题默认JobRepository使用内存数据库即使你配置了DataSource若未显式声明Bean它仍可能用HSQLDB导致Job状态不持久JobLauncher默认为同步实现SimpleJobLauncher会阻塞当前线程Web请求调用Job时HTTP连接会一直等待直到Job结束。解决方案是显式覆盖Configuration EnableBatchProcessing public class BatchConfig { Autowired private DataSource dataSource; // 覆盖默认JobRepository绑定到真实DataSource Bean public JobRepository jobRepository() throws Exception { JobRepositoryFactoryBean factory new JobRepositoryFactoryBean(); factory.setDataSource(dataSource); factory.setTransactionManager(transactionManager()); // 必须关联事务管理器 factory.setDatabaseType(mysql); // 指定数据库类型影响SQL方言 return factory.getObject(); } // 覆盖默认JobLauncher使用异步执行器 Bean public JobLauncher jobLauncher() throws Exception { SimpleJobLauncher launcher new SimpleJobLauncher(); launcher.setJobRepository(jobRepository()); // 关键设置异步执行器避免阻塞 launcher.setTaskExecutor(new SimpleAsyncTaskExecutor()); return launcher; } Bean public PlatformTransactionManager transactionManager() { return new DataSourceTransactionManager(dataSource); } }实操心得DatabaseType必须与实际数据库匹配mysql/postgresql/oracle否则JobRepository的SQL会出错。我曾因写成mysql5导致INSERT INTO BATCH_JOB_INSTANCE语法错误查了2小时才发现是类型名不对。4. 实操过程与核心环节实现4.1 订单实体与数据库准备最小可行数据模型为聚焦Batch逻辑数据库只建两张表order_info业务数据和Batch元数据表前文已建。order_info结构精简但覆盖典型字段CREATE TABLE order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(50) NOT NULL, amount DECIMAL(10,2) NOT NULL, status VARCHAR(20) NOT NULL DEFAULT PENDING, create_time DATETIME NOT NULL, remark TEXT ); -- 插入测试数据1000条 INSERT INTO order_info (order_no, amount, status, create_time, remark) SELECT CONCAT(ORD, LPAD(FLOOR(RAND()*1000000), 6, 0)), ROUND(RAND()*1000, 2), ELT(FLOOR(RAND()*3)1, PENDING, SHIPPED, CANCELLED), DATE_SUB(NOW(), INTERVAL FLOOR(RAND()*30) DAY), IF(RAND()0.8, 测试订单, NULL) FROM information_schema.columns c1, information_schema.columns c2 LIMIT 1000;对应的Java实体类Lombok简化Data NoArgsConstructor AllArgsConstructor public class Order { private Long id; private String orderNo; private BigDecimal amount; private String status; private LocalDateTime createTime; private String remark; }注意LocalDateTime在MySQL中对应DATETIME类型JDBC驱动会自动转换。若用Date类型需配置spring.jpa.database-platformorg.hibernate.dialect.MySQL8Dialect但Batch不依赖JPA所以直接用LocalDateTime更干净。4.2 Step-by-Step实现Reader→Processor→Writer的闭环4.2.1 ItemReader分页读取避免OOM核心是JdbcPagingItemReader它通过PagingQueryProvider分页查询而非一次性加载全表。配置要点Bean public ItemReaderOrder orderReader() { JdbcPagingItemReaderOrder reader new JdbcPagingItemReader(); reader.setDataSource(dataSource); reader.setFetchSize(100); // 每次JDBC fetch 100行减少网络往返 // 分页查询提供者按create_time排序避免id跳跃导致漏数据 MySqlPagingQueryProvider queryProvider new MySqlPagingQueryProvider(); queryProvider.setSelectClause(id, order_no, amount, status, create_time, remark); queryProvider.setFromClause(from order_info); queryProvider.setWhereClause(where status SHIPPED); queryProvider.setSortKeys(Collections.singletonMap(create_time, Order.ASCENDING)); reader.setQueryProvider(queryProvider); reader.setRowMapper(new BeanPropertyRowMapper(Order.class)); // 关键设置页大小控制内存占用 reader.setPageSize(100); // 每页读100条与ChunkSize对齐 return reader; }原理说明pageSize100意味着每次查询只取100条fetchSize100是JDBC底层每次从数据库缓冲区取100行。两者配合内存峰值≈100条Order对象大小约1MB远低于全表加载。若pageSize设为10000即使fetchSize100JdbcPagingItemReader仍会尝试加载10000条到内存导致OOM。4.2.2 ItemProcessor数据清洗与转换Processor负责业务逻辑此处做三件事金额格式化、时间标准化、空值填充。重点是抛出特定异常触发SkipBean public ItemProcessorOrder, OrderExportDto orderProcessor() { return order - { // 1. 金额转字符串保留两位小数 String amountStr Optional.ofNullable(order.getAmount()) .map(a - a.setScale(2, RoundingMode.HALF_UP).toString()) .orElse(0.00); // 2. 时间转标准字符串 String timeStr Optional.ofNullable(order.getCreateTime()) .map(t - t.format(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))) .orElse(1970-01-01 00:00:00); // 3. 空备注填充 String remark Optional.ofNullable(order.getRemark()).orElse(N/A); // 4. 关键模拟脏数据触发SkipPolicy if (INVALID.equals(order.getOrderNo())) { throw new IllegalArgumentException(Invalid order number: order.getOrderNo()); } return new OrderExportDto(order.getOrderNo(), amountStr, order.getStatus(), timeStr, remark); }; }对应的DTO用于CSV输出Data NoArgsConstructor AllArgsConstructor public class OrderExportDto { private String orderNo; private String amount; private String status; private String createTime; private String remark; }实操心得ItemProcessor必须是无状态的不能保存中间变量。我曾在一个项目中误用静态计数器统计处理条数结果多线程下计数错乱。正确做法是用StepExecutionListener的beforeStep/afterStep获取StepExecution.getWriteCount()。4.2.3 ItemWriterCSV文件生成与编码处理FlatFileItemWriter是写文件的主力但中文乱码是高频问题。根源在于OutputStreamWriter默认用平台编码Windows是GBKLinux是UTF-8而CSV需统一UTF-8。解决方案Bean public ItemWriterOrderExportDto orderWriter() { FlatFileItemWriterOrderExportDto writer new FlatFileItemWriter(); writer.setResource(new FileSystemResource(/tmp/export_orders_ LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE) .csv)); // 关键指定UTF-8编码避免中文乱码 writer.setLineAggregator(new DelimitedLineAggregatorOrderExportDto() {{ setDelimiter(,); setFieldExtractor(new BeanWrapperFieldExtractorOrderExportDto() {{ setNames(new String[]{orderNo, amount, status, createTime, remark}); }}); }}); // 设置编码核心 writer.setEncoding(UTF-8); // 添加Header可选 writer.setHeaderCallback(writer1 - { try { writer1.write(订单号,金额,状态,创建时间,备注); } catch (IOException e) { throw new RuntimeException(e); } }); return writer; }验证方法生成CSV后用file -i filename.csv检查编码。若显示charsetus-ascii说明写入时未生效需确认setEncoding(UTF-8)是否被调用。4.3 Job编排Chunk、Retry与Skip的协同Job的Step配置是性能与稳定性的核心。本示例采用chunk模式关键参数计算逻辑ChunkSize100每处理100条提交一次事务。选择依据MySQL单次事务建议≤1000条避免锁表时间过长100条对应内存约100KB安全。RetryLimit3对IllegalArgumentException重试3次。超过则进入Skip流程。SkipLimit10最多跳过10条脏数据超过则Job失败。完整Step配置Bean public Step exportOrderStep(ItemReaderOrder reader, ItemProcessorOrder, OrderExportDto processor, ItemWriterOrderExportDto writer) { return stepBuilderFactory.get(exportOrderStep) .Order, OrderExportDtochunk(100) // ChunkSize100 .reader(reader) .processor(processor) .writer(writer) .faultTolerant() // 启用容错 .retry(IllegalArgumentException.class) // 对此异常重试 .retryLimit(3) // 最多重试3次 .skip(IllegalArgumentException.class) // 对此异常跳过 .skipLimit(10) // 最多跳过10条 .listener(new OrderStepExecutionListener()) // 自定义监听器 .build(); } Bean public Job exportOrderJob(Step exportOrderStep) { return jobBuilderFactory.get(exportOrderJob) .start(exportOrderStep) .listener(new OrderJobExecutionListener()) // Job级监听器 .build(); }参数计算过程假设订单表100万条ChunkSize100则需1万次事务提交。若设为1000事务提交次数减为1000次但单次事务锁表时间变长可能阻塞线上订单写入。经压测100是MySQL 5.7下的最优平衡点。4.4 监控与可观测性让Job“看得见、管得住”Spring Batch自带JobExplorer和JobOperator但默认无Web界面。我们通过JobExecutionListener注入监控点Component public class OrderJobExecutionListener implements JobExecutionListener { private static final Logger log LoggerFactory.getLogger(OrderJobExecutionListener.class); Override public void beforeJob(JobExecution jobExecution) { log.info(Job {} started at {}, jobExecution.getJobInstance().getJobName(), jobExecution.getStartTime()); } Override public void afterJob(JobExecution jobExecution) { long duration Duration.between( jobExecution.getStartTime(), jobExecution.getEndTime()).toMinutes(); log.info(Job {} finished with status {}, duration {} min, processed {} items, jobExecution.getJobInstance().getJobName(), jobExecution.getStatus(), duration, jobExecution.getExecutionContext().getLong(totalProcessed, 0L)); // 关键推送指标到Prometheus示例伪代码 // Counter.builder(batch_job_total).tag(name, exportOrderJob).register(registry).increment(); } }配套的StepExecutionListener统计明细Component public class OrderStepExecutionListener implements StepExecutionListener { Override public void beforeStep(StepExecution stepExecution) { stepExecution.getExecutionContext().putLong(startTime, System.currentTimeMillis()); } Override public ExitStatus afterStep(StepExecution stepExecution) { long duration System.currentTimeMillis() - stepExecution.getExecutionContext().getLong(startTime); // 记录每步耗时 log.info(Step {} took {} ms, read {} items, written {} items, stepExecution.getStepName(), duration, stepExecution.getReadCount(), stepExecution.getWriteCount()); // 累加到Job上下文 stepExecution.getJobExecution().getExecutionContext() .merge(stepExecution.getExecutionContext()); return null; } }实操心得ExecutionContext是Job/Step的内存级KV存储重启后丢失。若需持久化统计应写入数据库或发送MQ。我在金融项目中将totalProcessed存入BATCH_JOB_EXECUTION_PARAMS表供BI系统拉取。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象根本原因解决方案java.lang.NoClassDefFoundError: javax/transaction/TransactionalSpring Boot 3.x使用Jakarta EE但依赖了旧版Spring Batch或JTA API检查pom.xml移除javax.transaction:javax.transaction-api添加jakarta.transaction:jakarta.transaction-apiJob执行后BATCH_JOB_EXECUTION表无记录JobRepository未正确绑定DataSource或DatabaseType配置错误在jobRepository()Bean中打印dataSource.getConnection().getMetaData().getURL()确认连接正常检查setDatabaseType(mysql)拼写CSV文件中文乱码Excel打开显示方块FlatFileItemWriter.setEncoding(UTF-8)未生效或操作系统默认编码干扰在writer.setResource()前加System.setProperty(file.encoding, UTF-8)用iconv -f gbk -t utf-8 input.csv output.csv验证文件编码Job启动时报NoSuchBeanDefinitionException: JobLauncherEnableBatchProcessing未生效或配置类未被ComponentScan扫描确认配置类上有Configuration检查包路径是否在SpringBootApplication的扫描范围内在main方法中System.out.println(context.getBeanNamesForType(JobLauncher.class).length)验证Bean存在处理10万条数据耗时2小时CPU持续100%ItemProcessor中存在同步IO如远程HTTP调用或复杂计算将远程调用改为异步CompletableFuture用Async标注Processor方法对计算密集型操作启用Scheduled(fixedDelay 5000)分批处理5.2 内存溢出OutOfMemoryError的深度排查OutOfMemoryError: insufficient memory在批量任务中高频出现但原因各异。我的排查路径确认OOM类型java.lang.OutOfMemoryError: Java heap space→ 堆内存不足java.lang.OutOfMemoryError: Metaspace→ 类加载过多如动态生成大量类java.lang.OutOfMemoryError: Direct buffer memory→ Netty或NIO直接内存泄漏。堆内存分析添加JVM参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/heap.hprof。用Eclipse MAT分析查看dominator_tree定位大对象若ArrayList或HashMap占70%以上检查ItemReader是否未分页如用了JdbcCursorItemReader而非JdbcPagingItemReader若String对象过多检查ItemProcessor是否缓存了未释放的字符串如new String(bytes, UTF-8)未关闭流。实战案例某次导出任务OOMMAT显示byte[]占95%。追踪发现FlatFileItemWriter的BufferedWriter内部char[]未及时flush。解决方案在writerBean中添加.bufferSize(8192)默认8192太小并确保FileSystemResource路径有写权限权限不足会导致Buffer累积。5.3 事务不回滚与数据不一致的根因Batch任务中“读取100条→处理→写入”是一个Chunk事务边界在此。常见不一致场景场景Processor中抛出RuntimeException但数据库已写入部分数据根因ItemWriter的write()方法未在事务内执行或DataSourceTransactionManager未正确代理验证在orderWriter()中加日志log.debug(Writing {} items, items.size())观察日志与数据库写入是否原子修复确保EnableBatchProcessing的transactionManager()Bean被JobRepository使用检查application.yml中spring.datasource.hikari.auto-commitfalseHikariCP必须关掉自动提交。独家技巧在Step配置中添加.allowStartIfComplete(true)避免Job重复执行导致数据重复。但需配合JobParametersIncrementer生成唯一参数否则JobInstance会冲突。5.4 面试高频题Spring Batch如何保证Exactly-Once语义这是Java中高级面试必问题。答案不是“它保证”而是“它提供机制需正确使用”Exactly-Once的前提Reader必须支持幂等读取如JdbcPagingItemReader按主键分页不会漏读/重读Writer必须支持幂等写入如JdbcBatchItemWriter的INSERT ... ON DUPLICATE KEY UPDATEProcessor必须无副作用不能调用外部API或调用时需保证幂等。Spring Batch的保障手段JobRepository持久化StepExecution的readCount/writeCount重启时从断点续跑Chunk的事务边界确保“读-处理-写”原子性JobParameters的incrementer保证同一参数不重复执行。反例若Writer是RestTemplate.postForObject()网络超时后Batch重试但服务端已处理就会重复下单。此时必须在服务端实现幂等Key如订单号而非依赖Batch。我在面试中常追问“如果Writer是发邮件怎么保证Exactly-Once”答案是邮件发送本身无法幂等应改为写入email_queue表幂等Insert再由独立服务消费队列发邮件。5.5 生产环境必备Job的启停与运维脚本开发环境用Scheduled触发生产环境需人工干预。提供两个Shell脚本启动Jobstart-job.sh#!/bin/bash # 参数JOB_NAME, JOB_PARAMS JOB_NAME$1 JOB_PARAMS$2 curl -X POST http://localhost:8080/batch/jobs/$JOB_NAME \ -H Content-Type: application/json \ -d {\$JOB_PARAMS\}查询Job状态query-job.sh#!/bin/bash # 参数EXECUTION_ID EXECUTION_ID$1 curl http://localhost:8080/batch/executions/$EXECUTION_ID注意需在Controller中暴露Endpoint。Spring Boot 3.x需自定义RestController因为spring-boot-starter-batch不再内置Web端点。示例ControllerRestController RequestMapping(/batch) public class BatchController { Autowired private JobLauncher jobLauncher; Autowired private JobLocator jobLocator; Autowired private JobExplorer jobExplorer; PostMapping(/jobs/{jobName}) public ResponseEntityString launchJob(PathVariable String jobName, RequestBody MapString, String params) { try { JobParameters jobParams new JobParametersBuilder() .addString(time, System.currentTimeMillis() ) .toJobParameters(); Job job jobLocator.getJob(jobName); JobExecution execution jobLauncher.run(job, jobParams); return ResponseEntity.ok(Job launched: execution.getId()); } catch (Exception e) { return ResponseEntity.badRequest().body(e.getMessage()); } } }我在银行项目中将这些脚本集成到Ansible Playbook配合Zabbix告警当BATCH_JOB_EXECUTION.STATUSFAILED持续5分钟自动触发query-job.sh并通知负责人。6. 性能调优与扩展方向6.1 ChunkSize与PageSize的黄金配比ChunkSize事务粒度和PageSizeReader分页大小的配比直接影响吞吐量。我的压测结论MySQL 5.716核32GChunkSizePageSize吞吐量条/秒CPU使用率锁表时间ms101012035%110010085065%2-510001000110095%15-30100010062070%8-12最优解ChunkSize PageSize 100。理由吞吐量达850条/秒满足90%业务需求CPU可控避免挤占在线交易线程锁表时间短不影响OLTP内存占用低100条×1KB≈100MBGC压力小。警告ChunkSize PageSize会导致Reader频繁查询ChunkSize PageSize会造成内存浪费。必须相等。6.2 分片Partitioning应对亿级数据当单机处理1亿条订单超时需分片。Spring Batch提供MultiResourceItemReader按文件分片和JdbcPartitioningStep按数据库分片。推荐后者原理Master Step查询SELECT MIN(id), MAX(id) FROM order_info按ID范围切分为10个PartitionWorker每个Partition由独立线程执行WHERE id BETWEEN ? AND ?关键配置PartitionHandler指定线程池Partitioner定义切分逻辑。示例PartitionerBean public ColumnRangePartitioner partitioner() { ColumnRangePartitioner partitioner new ColumnRangePartitioner(); partitioner.setColumn(id); partitioner.setDataSource(dataSource); partitioner.setTableName(order_info); partitioner.setWhereClause(status SHIPPED); return partitioner; }实操心得分片键必须是索引列如id否则WHERE id BETWEEN x AND y会全表扫描。我在物流项目中用create_time分片因未建索引查询耗时从200ms升至8秒。6.3 与现代技术栈的融合Spring Batch不是孤岛需融入云原生生态Kubernetes调度将Job打包为Job资源用CronJob定时触发restartPolicy: OnFailure确保失败重试消息队列解耦Writer不直接写文件而是发OrderExportEvent到RabbitMQ由独立Consumer写文件实现读写分离Serverless扩展AWS Batch或阿里云BatchCompute运行Job按需分配资源成本降低40%。我在跨境电商项目中用Spring Cloud Stream将Writer输出转为Kafka消息下游Flink实时计算导出完成率大屏展示各区域订单导出延迟。最后分享一个小技巧在application.yml中加logging.level.org.springframework.batchDEBUG可看到每Chunk的Committing Ongoing Transaction日志这是验证事务边界的最直接证据。真正的Batch高手不是API用得熟而是能从日志里读懂框架的心跳。