Spring Batch本地分区作业运行缓慢 单分区耗时15小时原因排查

场景固定参数对齐 #

• 业务基础：MongoDB 160万条记录全量同步至Oracle，本地Windows 10环境运行
• 现有配置：10个分区按id区间切分、单分区chunk大小为10、Mongo读取页大小为5、分区线程池最大线程数为10、本地模式JobRepository
• 异常表现：各分区执行时长从10秒到18分钟不等，partition6单次运行时长达到15小时48分钟，其余分区长期处于运行状态；理论上各分片数据量相近，存在极端分区执行倾斜

1. 分片切分逻辑的常见缺陷（80%概率对应partition6超时） #

• 最普遍踩坑：分片切分依赖Mongo offset跳数而非主键连续区间定位
  多数团队实现Mongo的Partitioner时，会先统计总文档量，再按总记录数/分区数计算每个分区的区间，通过skip(当前分区起始偏移量).limit(单分区数据量)的方式定位分片边界。这种逻辑下，partition6对应80万条记录之后的offset位置，Mongo对大offset的skip操作没有索引优化，每次翻页都需要从头遍历完所有前置文档才能定位到当前页。
  叠加当前配置的Mongo读取页大小仅为5，意味着80万offset之后的每一次翻页请求都要消耗数秒到数十秒的时间，单分区读取耗时被指数级放大，最终形成15小时级别的运行时长。
• 索引匹配失效
  即使是按id区间切分，如果切分键没有在Mongo集合上建立覆盖索引，或者查询条件的操作符导致索引无法命中（比如对id字段做了函数计算、模糊匹配），那么partition6的查询会退化为全集合扫描。如果刚好partition6对应的id区间在物理磁盘上的存储块是连续的、其余分区的查询走了索引，就会形成极致的倾斜差。
• id区间的数据体积实际不均
  按数值/字符串id线性切分的时候，很容易出现某一个区间的文档平均体积远大于其他区间的情况——比如partition6对应的区间存储了带大字段附件、长文本的历史数据，同样16万条记录的总传输量是其他分区的几十上百倍，读取、传输、写入Oracle的耗时自然被拉长。

2. MongoItemReader配置的性能缺陷 #

• 当前配置的Mongo读取页大小5 < 单分区chunk大小10，本身就存在设计问题：正常配置逻辑下页大小应≥chunk大小，保证一次页读取的数据可以直接凑齐至少1个chunk完成写入，避免每2次Mongo请求才能完成1次chunk提交。这种配置下160万条记录会触发32万次Mongo网络请求，整体性能下降70%以上。
• 如果读取逻辑中配置了与切分键不一致的排序规则（比如按创建时间排序而非按_id排序），Mongo需要将整个分区范围内的文档全部加载到内存完成排序，一旦内存占用超过阈值就会触发磁盘临时文件落盘，单次读取耗时会从毫秒级涨到分钟级。

3. 分区处理器与JobRepository的配置坑 #

• 线程池阻塞假象：当前配置的线程池最大线程数为10，如果队列容量配置为0、拒绝策略为CallerRunsPolicy，那么最先被调度的慢分区（比如partition6）会占满所有核心线程，其余9个分区根本无法进入执行队列，长期停留在“运行中”的状态，看起来像是分区耗时差异，实际是所有任务被慢任务堵死了。
• 本地JobRepository的锁竞争：如果本地JobRepository使用内存版H2数据库，多分区并发更新StepExecution、ExecutionContext状态时会触发行锁竞争。一旦partition6因为读取过慢，长期持有对应StepExecution的行锁不释放，其余分区每次状态更新都需要排队等锁，整体进度完全被卡住。
• 事务与重试配置问题：如果Worker Step没有配置chunk级事务提交，而是用单事务包裹整个分区的处理流程，一旦partition6碰到一条无法写入Oracle的脏数据（比如字段长度超限、类型不匹配），就会触发整分区事务回滚；如果默认重试次数配置过大，每次回滚都要重新遍历16万条记录的写入日志，耗时会被放大到几十小时级别。

• 重写Partitioner的分片逻辑：先全量扫描一次_id主键的分布点，按_id的连续值切10个无重叠的范围区间，彻底替换掉依赖offset skip的分片计算方式，从根源解决大offset查询的性能问题
• 调整Mongo读取页大小为10~20，匹配chunk=10的配置，减少Mongo的网络交互次数
• 校验每个分区的Mongo查询条件，确保完全命中_id主键索引，排除全集合扫描的可能
• 将本地JobRepository从内存H2切换为文件型H2/SQLite，降低多分区并发写入时的锁竞争
• 调整TaskExecutor的队列容量与分区数保持一致，拒绝策略改为AbortPolicy，避免慢任务占满线程后其余任务排队的假象
• 单独拉取partition6对应的id区间样本，检查文档平均大小、查询执行计划、是否存在持续重试的脏数据

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