Spring Repository保存大小约2,500,000的List时 saveAll与并行流逐条save哪种更快？

你需要保存规模约250万条的List，对比以下两种实现的性能差异：

1. 直接调用repository.saveAll(list)全量保存
2. 用并行流遍历逐条调用repository.save(e)单条保存

核心结论 #

在常规Spring Data JPA配置下，repository.saveAll(list)的性能会远优于list.parallelStream().forEach(e -> repository.save(e))，二者速度差距通常能达到几十到上百倍。

具体原因拆解 #

两种方案的性能差本质来自对数据库交互开销的控制能力：

• 标准配置下的saveAll(list)不会逐条和数据库交互，底层会依托Hibernate的JDBC批量能力，攒够指定批次的SQL后一次性发送给数据库，把原本250万次的网络往返、事务提交压缩到几十到几百次，同时会跳过单条保存时反复的实体状态校验、缓存刷新逻辑，大幅降低整体开销。
• 并行流单条调用save(e)的方案天然存在几个硬伤：
  1. 每条记录的保存都是独立的数据库交互，250万条意味着要产生250万次网络请求、250万次隐式事务提交，光是事务日志刷盘的开销就会把数据库拖垮
  2. parallelStream默认复用全局公共的ForkJoinPool，线程数和CPU核数绑定，既没有匹配数据库IO场景的线程规模，还会因为线程争抢数据库连接池的可用连接，产生大量锁等待，严重时甚至会把连接池打满报错
  3. 并行流的线程上下文和Spring的事务上下文无法正常传递，很容易出现事务失效、一级缓存错乱的问题，不只是运行速度慢，稳定性也没有保障

容易踩的配置误区 #

如果你的saveAll没有搭配正确的JPA批量配置，它的实际性能也会大幅缩水：

• 比如没有设置spring.jpa.properties.hibernate.jdbc.batch_size参数、没有开启批量插入开关、主键用了IDENTITY生成策略（会直接让Hibernate的批量能力失效），这种时候saveAll本质就是循环逐条保存，速度和普通串行for循环调用单条save没有区别。哪怕在这种场景下，它的整体速度也不会比并行流单条保存的方案差太多，依然是更稳妥的选择。

可落地的性能参考方案 #

• 250万条的全量List不要一次性传入saveAll，单批塞太多会导致JVM内存溢出、数据库端的SQL请求包过大，一般拆成1000-5000条/批逐批保存是性价比最高的选择
• 要让saveAll发挥批量性能，需要提前配套调整JPA配置：设置和批次大小匹配的batch_size、开启批量插入/更新开关，尽量避免用会让批量能力失效的IDENTITY主键生成策略
• 不推荐用parallelStream做数据库写入场景，真要做多线程拆分批次，也要手动配置和数据库连接池容量匹配的独立线程池，不要复用全局公共的ForkJoinPool，不然线程跑多了很容易把连接池占满。

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