在 Java 中，Lambda 表达式的主体可以访问外层的局部变量，但有一个前置条件：这个变量必须是 final 或者 effectively final，也就是本质上只赋值过一次。如果试图在 Lambda 内部执行 count++ 这样的自增操作，编译器会直接报错，因为自增破坏了 effectively final 约束。这个限制并不是语言设计者的随意决定，而是与 Lambda 的变量捕获方式、栈帧生命周期以及并发安全密切相关。理解这一点之后，就可以通过捕获可变容器或原子类来合法地实现变量自增。
本文会先说明 final 限制的底层原因，再介绍数组、包装类和 AtomicInteger 等几种突破方案，并对比它们在串行流与并行流中的表现，最后讨论更符合函数式风格的归约替代方案。
一、Lambda 为什么限制局部变量必须 final
Java 局部变量的生命周期与 Lambda 可能执行的生命周期并不一致。普通局部变量保存在当前线程的栈帧中，方法执行结束后栈帧销毁，变量也随之消失。而 Lambda 表达式在运行时会被转换为一个对象，它可能被传递到其他方法或线程中延迟执行。假如 Lambda 捕获的是一个可变局部变量，那么当方法结束后，Lambda 对象持有的变量副本和外部原始变量就会出现两个不同的存储位置。如果允许两边同时修改，程序会面临数据竞争和同步难题。
为了避免这种复杂且容易出错的语义，Java 设计者要求被 Lambda 捕获的局部变量必须是 final 或 effectively final。这里的 effectively final 是指变量虽然没有显式写上 final，但从初始化之后就不再发生变化。下面这段代码会直接编译失败：
List<String> names = Arrays.asList("a", "b", "c");
int count = 0;
names.forEach(n -> count++); // 编译错误：count 不是 effectively final
编译器会发现 count 在 Lambda 内部被修改，从而拒绝编译。这个错误的本质，并不是 Java 不允许累加，而是不允许在 Lambda 中改变被捕获局部变量的值。要绕过这个限制，关键不是把变量变得可重新赋值，而是让被捕获的引用指向一个可变对象。
二、利用数组和可变包装类实现自增
最常见的做法是使用一个数组作为容器。数组引用本身可以被声明为 final，但数组元素可以自由修改。由于 Lambda 捕获的是数组引用，而不是数组元素，因此引用没有发生改变，符合 effectively final 的要求。代码示例如下：
int[] counter = {0};
List<String> names = Arrays.asList("a", "b", "c");
names.forEach(n -> {
if (n.startsWith("a")) {
counter[0]++;
}
});
System.out.println(counter[0]); // 输出匹配项数量
这段代码中 counter 从未被重新赋值，改变的只是 counter[0] 的内容。对于串行流来说，这样写完全可行，代码也足够直观。不过数组方案有两个明显缺点：一是可读性一般，counter[0] 并不能一眼看出它表示什么语义；二是数组元素的自增操作不具备原子性，一旦换成 parallelStream，多个线程同时修改 counter[0] 就可能丢失更新。
如果希望代码表达更清晰，可以自己定义一个可变的包装类，例如 MutableInt：
class MutableInt {
private int value;
public MutableInt(int value) {
this.value = value;
}
public void increment() {
value++;
}
public int getValue() {
return value;
}
}
MutableInt counter = new MutableInt(0);
names.forEach(n -> counter.increment());
System.out.println(counter.getValue());
这种写法比数组更易读，counter.increment() 直接表达了自增语义。它同样适用于串行流，但在并行流中依然不是线程安全的。包装类只是把可变状态封装在对象内部，并没有提供同步或原子性保证。因此选择数组还是包装类，主要取决于代码可读性要求，而不是并发安全要求。
三、使用 AtomicInteger 兼顾线程安全与自增
如果 Lambda 可能运行在并行流中，或者任务会被提交到线程池并发执行，那么就需要使用 AtomicInteger。它内部通过 CAS 循环来保证自增操作的原子性，多个线程同时调用 incrementAndGet() 也不会丢失更新。示例代码如下：
AtomicInteger counter = new AtomicInteger();
List<String> names = Arrays.asList("alpha", "beta", "gamma");
names.parallelStream().forEach(n -> {
if (n.length() > 4) {
counter.incrementAndGet();
}
});
System.out.println(counter.get());
AtomicInteger 可以安全地用于并行流场景，因为每次自增都是原子操作。它的缺点是性能比简单的数组或包装类稍差，在高竞争场景下 CAS 可能多次重试。不过只要竞争不是极端激烈，AtomicInteger 的开销通常可以忽略。相比自定义锁或同步块，它更简洁，也是处理计数累加的标准工具。
需要特别注意的是，不要把数组自增直接用在 parallelStream 中。下面这种写法存在经典的丢失更新问题：
int[] counter = {0};
names.parallelStream().forEach(n -> counter[0]++);
System.out.println(counter[0]); // 结果可能小于实际列表大小
因为 counter[0]++ 并不是一个原子操作，它实际上包含读取、加一、写回三个步骤。多个线程可能同时读到同一个旧值，导致最终结果偏小。因此，当代码可能运行在并行环境下时，应该优先选择 AtomicInteger。
四、优先考虑函数式归约替代可变状态
虽然可以通过数组、包装类和 AtomicInteger 在 Lambda 中实现变量自增，但从函数式编程的角度看，这仍然属于副作用。副作用会让代码更难推理，也不利于流式操作的组合与优化。很多时候，计数和累加完全可以使用 filter、mapToInt、reduce 等方法完成，不需要维护外部可变状态。
例如统计以某个前缀开头的元素数量，直接使用 filter 配合 count 即可：
long count = names.stream()
.filter(n -> n.startsWith("a"))
.count();
如果要对数值列表求和，可以使用 mapToInt 配合 sum：
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
int total = numbers.stream()
.mapToInt(Integer::intValue)
.sum();
更通用的做法是使用 reduce，它在并行流中也能得到正确结果：
int total = numbers.stream()
.reduce(0, (a, b) -> a + b);
这些方法把累加逻辑交给流框架处理，避免了外部变量和线程安全问题。当然，并不是所有场景都适合完全函数式。例如需要在遍历过程中收集多种统计信息，或者需要根据外部环境动态决定是否累加时，保留一个 MutableInt 或 AtomicInteger 可能更直观。关键在于区分场景：简单的单值计数优先用流的 count 或 sum；复杂的多状态统计可以使用包装类；涉及并行执行时使用 AtomicInteger。理解了 Lambda 的 final 限制后，再根据具体需求选择合适的方案，才能写出既安全又清晰的代码。