除可读性外，使用Java Stream标准方法而非forEach的优势有哪些？

除了可读性之外，用Stream的标准中间操作和终止操作替代全forEach的写法，还有这些核心优势：

• 无副作用，线程安全有保障
  同事的写法里直接在forEach的lambda里操作外部集合secondInts，属于带副作用的代码。如果哪天把stream()改成parallelStream()，因为ArrayList不是线程安全集合，大概率会出现并发修改异常、元素丢失或者重复的问题。而用toList()的替代方案，Stream内部会负责线程安全的结果收集，并行场景下不用额外做同步处理。

• 逻辑职责单一，声明式更清晰
  forEach把「筛选条件判断」和「元素收集」混在同一个lambda里，读代码得仔细看内部逻辑才知道到底在做什么。而filter(i -> i%6==0)直接明说“只留能被6整除的元素”，toList()明说“把结果收集成列表”，每一步操作职责明确，别人扫一眼链式调用就懂整体逻辑，不需要拆解lambda里的分支。

• 可组合、易扩展
  如果后续要给逻辑加新步骤（比如筛选后把数字转成字符串、再去重），用标准操作直接链式追加就行：

  List<String> result = numbersList.stream()
      .filter(i -> i%6==0)
      .map(String::valueOf)
      .distinct()
      .toList();
  

  但用forEach的话，只能往lambda里堆逻辑，代码会越来越臃肿，时间长了容易变成难以维护的“大泥块”。

• 减少手动集合管理的冗余与错误
  像替代方案2完全不需要手动new ArrayList<>()，Stream的toList()会自动处理集合的创建和元素填充，省掉了初始化集合的代码，也避免了选错集合类型（比如误选LinkedList导致频繁扩容性能差）、忘记初始化集合这类低级错误。

• 性能优化空间更大
  Stream的标准操作是Java官方优化过的，比如并行流场景下，collect操作会自动用高效的收集策略平衡线程负载；而forEach手动往外部集合加元素，要是用线程安全集合还得加锁，反而拖慢性能。另外JVM对Stream的中间操作（比如filter、map）能做融合优化，forEach里的逻辑是黑盒，很难被JVM优化。

代码示例对比 #

List<Integer> firstInts = new ArrayList<>();
List<Integer> secondInts = new ArrayList<>();
List<Integer> numbersList = IntStream.range(0, max).boxed().toList();

// 同事的全forEach实现
numbersList.stream()
       .forEach(i -> {
           if(i % 6 != 0) {
               return;
           }
           secondInts.add(i);
       });

// 替代方案1：filter+forEach
numbersList.stream()
        .filter(i -> i % 6 == 0)
        .forEach(firstInts::add);

// 替代方案2：filter+toList（推荐）
List<Integer> third = numbersList.stream()
        .filter(i -> i % 6 == 0)
        .toList();

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