升级Spring Boot3/Spring Batch5与JDK17后文件写入速度骤降问题排查

问题背景 #

我有一个Spring Batch应用，自定义了Writer步骤用于批量写入大量实体到文件。升级到Spring Boot 3/Spring Batch 5前该步骤执行速度很快，但升级后写入速度变得异常缓慢。

自定义Writer的核心代码如下：

@Override
protected String doWrite(Chunk<? extends List<ExportData>> chunk) {
    StringBuilder lines = new StringBuilder();

    List<ExportData> list = chunk.getItems().stream().flatMap(List::stream).collect(Collectors.toList());
    for (ExportData item : list) {
        lines.append(this.lineAggregator.aggregate(item)).append(this.lineSeparator);
    }
    return lines.toString();
}

可能的原因 #

• Stream操作的累积开销：Spring Batch 5要求Java 17+，新版本JVM对Stream的实现可能存在细微性能差异；当chunk包含大量List<ExportData>元素时，stream().flatMap().collect()会产生大量临时对象，触发更频繁的GC，拖慢整体速度。
• StringBuilder频繁扩容：默认StringBuilder初始容量仅16，若单条数据较长且chunk数据量较大，会反复触发扩容（每次扩容需复制字符数组）。Spring Batch 5可能调整了默认chunk大小，单次处理数据量更大，加剧了这个问题。
• LineAggregator逻辑变更：如果使用的是Spring Batch自带的LineAggregator实现（如DelimitedLineAggregator），Spring Batch 5可能对其内部逻辑做了修改（比如增加校验、格式化步骤），导致单条数据聚合耗时增加，批量处理时被放大。
• Chunk处理流程重构：Spring Batch 5对Chunk的处理逻辑做了重构，比如增加了额外的监听器调用、事务校验逻辑，或者自定义Writer的调用方式改变，间接影响了doWrite方法的执行效率。

可行的排查方法 #

• 替换Stream为普通循环对比性能：把流操作改成嵌套循环，看性能是否提升：

  List<ExportData> list = new ArrayList<>();
  for (List<ExportData> subList : chunk.getItems()) {
      list.addAll(subList);
  }
  

  如果性能明显变好，说明Stream操作是瓶颈。
• 指定StringBuilder初始容量：估算单条数据平均长度和chunk总数据量，设置初始容量避免扩容：

  // 示例：假设单条数据平均长度100，换行符长度2
  int totalItems = chunk.getItems().stream().mapToInt(List::size).sum();
  int estimatedCapacity = totalItems * 100 + totalItems * lineSeparator.length();
  StringBuilder lines = new StringBuilder(estimatedCapacity);
  

• 单独测试LineAggregator性能：批量调用lineAggregator.aggregate(item)并统计耗时，对比新旧版本的执行速度，确认是否是聚合逻辑本身变慢。
• 监控JVM内存与GC：用jconsole、jprofiler等工具观察GC频率、内存占用。如果频繁GC，说明是临时对象（如Stream操作产生的对象、扩容后的字符数组）导致的内存压力。
• 检查Chunk大小配置：对比新旧版本的spring.batch.chunk.size配置，若新版本默认chunk更大，单次处理数据量增加会放大原有代码的性能问题。
• 查阅Spring Batch 5变更日志：重点查看ItemWriter、Chunk处理相关的性能变更或已知bug，确认是否有官方记录的性能退化问题，以及对应的修复或调整方案。

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