Spring Boot中静态List跨控制器共享的合理性及风险咨询

你的方案目前能正常运行，但存在几个易被忽略的潜在风险，并非完全可靠的实现方式，具体问题如下：

一、静态集合的线程安全隐患 #

如果你使用的是ArrayList这类非线程安全集合，会面临两种问题：

• 若更新逻辑是修改原集合（比如先clear()再批量add()），控制器线程在读取/遍历集合时，大概率会触发ConcurrentModificationException，或者读到半更新的残缺数据。
• 就算是直接给静态变量重新赋值（比如refDataList = new ArrayList<>(新数据)），虽然变量赋值是原子操作，但如果RefData是可变对象，且更新时存在修改对象内部属性的操作，控制器线程仍可能读到不一致的对象状态。

二、parallelStream的潜在风险 #

你使用parallelStream的出发点没问题，但要注意两个关键点：

• parallelStream默认使用ForkJoinPool.commonPool()，如果你的控制器定时任务、Spring其他异步任务也依赖这个公共线程池，会导致线程资源竞争，所有依赖该池的任务性能都会下降，甚至出现任务堆积。
• 如果RefData是可变对象，在parallelStream处理（哪怕只是读取）时刚好赶上更新线程修改对象属性，会出现数据不一致的情况；另外，parallelStream的未捕获异常可能直接终止线程池中的工作线程，影响后续任务执行。

三、定时更新的并发冲突 #

如果定时任务用的是fixedRate（固定间隔触发），当数据库查询或数据处理耗时超过4秒时，会出现多个更新任务同时执行的情况：

• 重复查询数据库，额外增加数据库压力；
• 若更新逻辑是修改原集合，多个更新线程同时操作会导致数据混乱，甚至抛出并发异常。

优化建议 #

• 改用线程安全集合：用CopyOnWriteArrayList替代普通List，它适合读多写少的场景，读取时无锁，更新时会复制一份新集合，避免并发修改问题。
• 原子性替换集合：更新时先完成数据库查询和数据组装，得到新的List实例后再直接赋值给静态变量，而非修改原集合。示例代码：

  private static List<RefData> refDataList;
  
  // 定时更新方法
  public void updateRefData() {
      List<RefData> newData = queryFromDb(); // 从数据库查询新数据
      refDataList = newData; // 原子替换集合
  }
  

• 合理使用parallelStream：如果数据量不大，串行stream性能足够，没必要用parallelStream；如果必须使用，自定义ForkJoinPool隔离线程资源，避免和其他任务冲突。
• 控制定时任务并发：用fixedDelay替代fixedRate，确保上一次更新完成后再触发下一次；或者在更新方法上加锁（比如synchronized），避免多个更新线程同时执行。

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