播面

在 Java 中，Stream API 是基于函数式编程（Functional Programming）思想设计的。不建议在 Stream 的中间操作（如 filter、map）中修改外部局部变量，主要原因可以归结为以下四个核心点：

1. 线程安全与并发问题（最致命的原因）

Stream 的一大优势是可以非常方便地转换为并行流（parallelStream()）来利用多核 CPU。

如果你在 Stream 操作中修改外部变量，当切换到并行流时，多个线程会同时读写这个共享的外部变量，从而导致严重的竞态条件（Race Condition）和数据不一致。

错误示例：

int[] sum = {0}; // 外部局部变量（用数组绕过 effectively final 限制）
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

// 如果换成 parallelStream()，结果将是随机的、不正确的
numbers.parallelStream()
       .map(x -> {
           sum[0] += x; // 外部状态修改
           return x;
       })
       .collect(Collectors.toList());

System.out.println(sum[0]); // 并行运行时，结果极大概率不等于 15

正确做法：应该使用 Stream 提供的规约（Reduction）操作，如 reduce 或 collect。

int total = numbers.parallelStream()
                   .reduce(0, Integer::sum); // 线程安全

2. 惰性求值与执行顺序的不可预测性

Stream 的中间操作（filter、map、peek 等）是惰性求值（Lazy Evaluation）的。它们只有在遇到终端操作（如 collect、forEach、findFirst）时才会真正执行。

此外，某些操作是短路（Short-circuiting）的。这意味着流可能会在处理完所有元素之前就终止。

示例：

List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> counter = new ArrayList<>(); // 外部变量

Optional<Integer> result = list.stream()
       .filter(x -> {
           counter.add(x); // 修改外部变量
           return x > 2;
       })
       .findFirst(); // 短路操作，找到第一个满足条件的就停止

在上面的代码中：

• 如果没有 findFirst()，counter.add(x) 根本不会执行。
• 因为有 findFirst()，流在遇到 3 时就会停止。此时 counter 里只有 [1, 2, 3]，而不是整个列表。这导致外部变量的状态取决于 Stream 的执行细节，极难预测和调试。

3. 违背了函数式编程的“无副作用”原则

Stream 的设计哲学是“无副作用”（Side-Effect-Free）。

• 副作用是指：一个函数除了返回一个值之外，还修改了外部的状态（如修改全局变量、写文件等）。
• 纯函数（Pure Function）：输入相同，输出必定相同，且不产生副作用。

filter 和 map 应该充当纯函数。如果它们修改了外部变量，代码的可读性、可维护性和可测试性都会急剧下降。后续阅读代码的人很难一眼看出这个 Stream 操作居然偷偷改变了外面的数据。

4. 违反了 Java 闭包的 "Effectively Final" 限制

Java 编译器本身就不鼓励这种行为。在 Lambda 表达式中引入外部局部变量时，该变量必须是 final 或 effectively final（实际上的最终变量，即不重新赋值）。

为了绕开这个限制，开发者不得不使用一些“歪门邪道”（例如使用单元素数组 int[]，或者 AtomicInteger）。

// 编译报错：Local variable sum defined in an enclosing scope must be final or effectively final
int sum = 0;
list.stream().forEach(x -> sum += x); 

既然编译器已经通过这个限制在警告你“不要修改外部变量”，那么通过包装类或数组去强行突破这个限制，无疑是一种代码异味（Code Smell）。

总结与最佳实践

黄金法则：
Stream 管道中的中间操作应该只负责转换和过滤数据，把数据的收集和状态的改变留给终端操作（Terminal Operations），或者完全交给安全的容器去承载。