Spring Batch数据删除任务性能缓慢问题排查求助

问题背景 #

我们团队基于Spring Batch实现定期数据库数据删除任务，采用面向chunk的处理模式（而非Tasklets），使用组件为：

• JpaPagingItemReader（读取根实体Group）
• 自定义ItemProcessor（处理关联数据删除）
• RepositoryItemWriter（删除根实体）

处理流程：Reader按pageSize/chunkSize=1000批量读取Group实体；Processor中通过JpaRepository删除关联的用户、活动数据；Writer删除Group根实体。

当前问题：任务前期（前400页）处理速度较快，之后Processor日志生成明显变慢，已排除Reader的查询性能问题，需定位Processor环节性能下降的原因。

代码片段 #

Reader #

// omit
val reader: JpaPagingItemReader<Group> = object : JpaPagingItemReader<Group>() {
    override fun getPage(): Int {
        return 0
    }
}.apply {
    pageSize = batchPageSize
    setName("reader")
    setEntityManagerFactory(entityManagerFactory)
    setQueryString(
        "SELECT g FROM Group g " +
                "WHERE (g.type = 'A' OR g.type IS NULL) " +
                "   AND (g.dateLastUpdated < '$expiredDate' OR g.dateLastUpdated IS NULL) " +
                "ORDER BY g.id")
}

return reader
// omit

Processor #

@Bean
@StepScope
fun processor(): ItemProcessor<Group, Group> {
    return ItemProcessor { group ->
        log.info("PROCESSOR-START: DELETE EXPIRED GROUP group id {}", group.id)
        val users = userRepository.findByGroup(group)
        activityRepository.deleteByUsers(users )
        // omit
        group
    }
}

Writer #

@Bean
@StepScope
fun writer(): RepositoryItemWriter<Group> {
    RepositoryItemWriter<Group>().let {
        it.setRepository(groupRepository)
        it.setMethodName("delete")
        return it
    }
}

可能的性能瓶颈及排查方向 #

1. EntityManager上下文膨胀 #

Processor中每次查询关联数据、执行删除操作时，EntityManager会缓存大量实体对象。随着处理批次增多，缓存持续膨胀，导致JVM内存占用飙升、GC频繁触发，直接拖慢后续操作速度。

2. 关联操作未做批量优化 #

• userRepository.findByGroup(group)若采用单条查询或返回全量实体，会引发N+1查询问题；且activityRepository.deleteByUsers(users)如果是循环删除单条记录（而非批量SQL），会生成大量DELETE语句，数据库交互次数暴增，压力陡增。
• RepositoryItemWriter使用的delete方法若为单条删除，chunkSize=1000的批量优势完全无法发挥。

3. Reader的自定义分页逻辑错误 #

重写JpaPagingItemReader的getPage()固定返回0，会导致Reader每次都读取第一页数据。前期数据未被删除时重复处理同一批数据，后期数据被删除后查询空结果，无效操作增多，间接拖慢整体速度。

4. 数据库层面瓶颈 #

• 关联字段无索引：user表的group_id、activity表的user_id若未建索引，查询和删除时会触发全表扫描，数据量越大速度越慢。
• 事务日志IO瓶颈：大量删除操作产生的事务日志（如MySQL binlog）刷盘耗时增加，导致数据库操作等待。
• 连接池不足：Processor中的数据库操作等待连接，导致处理延迟。

排查与优化建议 #

1. 清理EntityManager缓存 #

• 注入EntityManager，在Processor处理完每个chunk后调用entityManager.clear()，手动清理缓存，避免上下文膨胀。
• 配置JpaPagingItemReader时设置setUseSharedEntityManager(false)，使用独立EntityManager，减少缓存累积。

2. 优化关联数据删除逻辑 #

• 将userRepository.findByGroup(group)改为基于groupId的批量查询JPQL：SELECT u FROM User u WHERE u.group.id = :groupId，避免传递实体带来的额外开销。
• 将activityRepository.deleteByUsers(users)改为批量删除JPQL：DELETE FROM Activity a WHERE a.user.group.id = :groupId，直接通过groupId关联删除，无需先查询用户列表，减少数据库交互次数。
• 优先使用批量SQL操作，避免加载实体后再删除，降低内存占用。

3. 修复Reader分页逻辑 #

删除自定义的getPage()重写，依赖JpaPagingItemReader默认的自动分页递增逻辑，避免重复读取或无效查询。

4. 数据库优化 #

• 为user表的group_id、activity表的user_id添加索引，消除全表扫描。
• 查看数据库慢查询日志，定位具体慢SQL并优化。
• 根据业务容忍度调整数据库事务日志刷盘策略（如MySQL设置innodb_flush_log_at_trx_commit=2），减少IO等待。

5. 性能监控 #

• 监控JVM GC情况，查看是否存在频繁Full GC或内存泄漏。
• 监控数据库连接数、锁等待状态，排查锁竞争问题。
• 利用Spring Batch自带监控指标，统计每个chunk的处理时间，定位性能骤降的具体节点。

附：Processor日志生成速度逐渐变慢（日志堆积情况如图）

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