Spring Batch多层级项嵌套处理及嵌套作业事务问题求解

问题根因 #

你当前遇到的子作业执行卡住、事务异常问题，核心是违反了Spring Batch的核心设计约束：禁止在运行中作业的事务上下文（包括ItemWriter、ItemProcessor的Chunk执行逻辑内）直接通过同步JobLauncher启动子作业。
你添加的factory.setValidateTransactionState(false)配置只是强行关闭了框架的事务合法性校验，并没有解决事务边界冲突、元数据锁互斥的本质问题。子作业读取第二个条目时卡死，是典型的事务死锁表现：父作业的Chunk事务持有了JobRepository元数据表的行锁，子作业启动时需要更新同一组元数据记录，锁互斥导致线程永久阻塞。官方文档明确提到关闭事务校验会导致作业重启能力失效、多线程步骤死锁，这个配置不能作为生产环境的解决方案。

推荐实现方案：原生分区步+嵌套作业 #

这是Spring Batch官方支持的多层级处理标准实现，天然满足方法复用、断点续跑、多线程并行的需求，不需要修改任何默认事务校验配置：
整体逻辑按你的三层结构拆分，每一层通过分区器（Partitioner）把当前层级的单个处理条目生成分区上下文，传递给下一级的处理步骤/子作业，所有步骤的事务、生命周期、执行状态全由框架原生托管：

• 第一层（国家维度）作业：
  • 步骤1：完成国家维度数据的读、处理、写操作
  • 步骤2：配置为分区主步骤，通过国家分区器把每个国家ID封装为独立分区上下文，分发给从属工作步骤，可直接配置线程池实现多国家并行处理
• 第二层（CSV列表维度）从属步骤：
  • 绑定分区上下文传入的国家ID，读取对应国家下的所有CSV列表，完成CSV列表维度的读、处理、写操作
  • 嵌套下一级分区主步骤，通过CSV列表分区器把每个CSV列表ID封装为独立分区上下文，分发给下一级从属工作步骤
• 第三层（单个CSV维度）从属步骤：
  • 绑定分区上下文传入的CSV列表ID，读取列表下的单个CSV文件，直接调用封装好的单CSV处理子作业完成读写逻辑
    核心配置示例：

// 国家级分区主步骤配置
@Bean
public Step countryPartitionStep() {
    return stepBuilderFactory.get("countryPartitionStep")
            .partitioner(csvListLevelStep().getName(), countryPartitioner())
            .step(csvListLevelStep())
            .gridSize(threadPoolSize) // 自定义并行度
            .taskExecutor(batchTaskExecutor()) // 配置线程池实现多线程处理
            .build();
}

// 单国家对应的CSV列表处理步骤，内部嵌套CSV级分区
@Bean
public Step csvListLevelStep() {
    return stepBuilderFactory.get("csvListLevelStep")
            .<CsvList, CsvList>chunk(chunkSize)
            .reader(csvListReader(null)) // 从分区上下文获取当前国家ID，过滤读取对应CSV列表
            .processor(csvListProcessor())
            .writer(csvListWriter())
            .build();
}

这种实现方式下，单个条目处理时会自动触发下一级逻辑，所有执行状态持久化到JobRepository元数据表，某个层级处理失败后重启作业，会自动跳过已经处理成功的条目，从失败位置恢复，完全不需要自定义事务逻辑。

备选方案：ItemWriter内异步触发子作业 #

如果现有逻辑重构成本过高，必须在ItemWriter内触发子作业，需要做以下修正，绝对不能只关闭事务校验：

1. 移除writeItem方法上的@Transactional(propagation = Propagation.REQUIRES_NEW)注解：Spring Batch的Chunk操作本身已经由框架托管事务边界，自定义事务注解会和框架的事务管理器产生冲突，导致事务边界混乱。
2. 配置独立的异步JobLauncher，让子作业在脱离父作业事务上下文的独立线程中执行：

@Bean
public JobLauncher asyncJobLauncher() throws Exception {
    SimpleJobLauncher launcher = new SimpleJobLauncher();
    launcher.setJobRepository(jobRepository);
    launcher.setTaskExecutor(new SimpleAsyncTaskExecutor()); // 异步线程池执行子作业
    launcher.afterPropertiesSet();
    return launcher;
}

3. Writer内调用子作业时使用上述异步JobLauncher，同时删除factory.setValidateTransactionState(false)配置，恢复框架默认的事务校验逻辑。

注意：该方案存在明显缺陷：父作业不会等待子作业执行完成就会标记当前Chunk处理成功，父子作业的执行状态没有绑定，断点续跑、失败回滚逻辑需要自行实现，仅作为临时兼容方案使用，不推荐生产环境优先采用。

避坑提示 #

不要在ItemProcessor/ItemWriter的业务逻辑中直接调用同步JobLauncher启动子作业。Spring Batch的JobRepository元数据操作要求独立的事务边界，和业务Chunk事务混跑必然会出现死锁、状态不一致、重启逻辑失效的问题。

内容的提问来源于stack exchange，提问作者eim equipazo