Spring Batch分片场景下跳过序列化/反序列化以支撑百万级数据复制

针对你遇到的MapStepExecutionDao序列化导致OOM的问题，逐个解答你的疑问：

1. 是否可跳过StepExecution的序列化/反序列化操作？ #

可以跳过，但要先评估风险。MapStepExecutionDao用序列化拷贝的核心目的是避免多线程并发修改同一份StepExecution对象导致的状态不一致。如果你的分片任务中，每个StepExecution只会被单个线程处理（比如分片逻辑保证每个分片的执行上下文独立且无共享修改），那么跳过序列化拷贝不会引发一致性问题。但如果存在并发修改的可能，跳过会导致JobRepository中的StepExecution状态混乱。

2. Spring Batch是否有配置可避免序列化/反序列化？ #

没有直接的配置开关禁用这个逻辑。因为MapStepExecutionDao是内存型JobRepository的默认实现，设计上就依赖序列化来做对象隔离。要从配置层面规避，最直接的方式是替换为JDBC-based的JobRepository：Spring Batch提供的JdbcStepExecutionDao会将StepExecution（包括大型ExecutionContext）序列化后存储到数据库，而不是在内存中反复生成byte[]和字符串副本，从根源减少内存占用。

3. 是否可扩展或重写该行为？ #

当然可以，有两种可行方案：

• 重写MapStepExecutionDao的拷贝逻辑：
  继承MapStepExecutionDao，自定义属性拷贝逻辑替代序列化反序列化（原copy方法是私有，需通过子类重新实现类似逻辑）。比如手动复制StepExecution的id、状态、指标等字段，对于ExecutionContext，若能保证无并发修改，可直接传递引用，避免大字符串的重复拷贝。示例伪代码：

  public class CustomMapStepExecutionDao extends MapStepExecutionDao {
      private StepExecution copy(StepExecution original) {
          StepExecution copy = new StepExecution(original.getStepName(), original.getJobExecution());
          copy.setId(original.getId());
          copy.setStatus(original.getStatus());
          // 手动复制其他必要字段，ExecutionContext直接复用引用（需保证无并发修改）
          copy.setExecutionContext(original.getExecutionContext());
          // 补充其他属性复制逻辑
          return copy;
      }
  }
  

• 替换JobRepository的DAO实现：
  直接配置使用JdbcStepExecutionDao，将JobRepository持久化到数据库。这种方式无需修改核心逻辑，Spring Batch会自动将StepExecution的状态（包括大型ExecutionContext）写入数据库，内存中不会累积大量序列化后的对象，彻底解决OOM问题。这也是处理百万级分片任务的推荐方案，因为内存型JobRepository本身就不适合大规模任务场景。

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