Spring Batch同表读写多线程部署时RepositoryItemReader漏读如何解决？

你遇到的漏读问题本质是分页查询的结果集会随处理逻辑动态变化：每次处理完一批数据后你会更新COLUMN1字段为非空，导致下一次分页查询时符合WHERE条件的总记录数减少，分页偏移量计算错位，就会出现固定比例的记录被跳过的情况，这是分页读组件在多线程+更新查询条件字段场景下的典型问题。
额外补充：你原查询语句里的COLUMN1 = NULL语法不符合SQL规范，正确写法是COLUMN1 IS NULL，不过这不是本次漏读问题的核心诱因。

• 方案1：使用Spring Batch分区（Partitioning）处理 #

  替换当前多线程ItemReader的实现，改用分区模式：先将待处理的全量数据按主键范围、哈希取模等规则拆分为多个互不重叠的独立分区，每个分区分配给独立线程处理。每个分区的查询条件固定绑定对应分区的范围，比如WHERE ID BETWEEN 1 AND 1000 AND COLUMN1 IS NULL，不同分区的查询、处理完全隔离，不会出现分页偏移错位的问题，是大数据量多线程批处理的最优方案。

• 方案2：基于主键队列的拉取模式 #

  第一步先执行SELECT ID FROM TABLE1 WHERE COLUMN1 IS NULL一次性获取所有待处理记录的主键，存入线程安全的队列中。后续启动多线程消费队列，每个线程按拿到的主键查询单条记录执行后续处理逻辑。该方案完全规避了分页查询的偏移问题，实现逻辑简单，适合数据量级在百万以内的场景。

• 方案3：改用游标ItemReader #

  替换分页式的RepositoryItemReader为JdbcCursorItemReader，游标会在任务启动时一次性打开符合条件的结果集，后续处理过程中你对COLUMN1的更新不会影响已经打开的游标结果集，天然规避了分页错位问题。注意游标读本身是线程不安全的，需要配置JDBC驱动的游标预拉取参数，搭配异步处理器实现多线程处理。

如果待处理的单条记录体积很小，10万条总内存占用控制在JVM堆内存的10%以内，短期使用大页配置是可以的，但该方案存在明显的扩展性问题：如果后续数据量涨到百万级，大页查询会导致内存占用过高甚至OOM问题，不建议作为长期方案使用。

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