Lambda表达式本身不保证线程安全，关键在于变量的共享方式与可变性；应避免共享可变状态，或对共享可变状态施加正确同步。
Java 中 Lambda 表达式本身不提供线程安全性，它只是语法糖，关键在于你如何使用它访问和修改变量。所谓“安全共享”，不是让 Lambda 自动变安全，而是通过控制变量的可见性、可变性与访问方式，避免竞态条件。核心原则是：**不共享可变状态，或对共享可变状态施加正确同步**。
明确变量来源：局部变量 vs 实例/静态变量
Lambda 捕获的变量类型决定了风险等级：
- 有效 final 的局部变量（含隐式 final）：Lambda 捕获的是值拷贝（基本类型）或引用拷贝（对象）。多个线程读取没问题，但若该对象本身可变（如 ArrayList），且被多个线程并发修改，仍会出错——问题不在 Lambda，而在对象本身非线程安全。
- 实例字段或静态变量：这才是真正的“共享变量”。多个线程通过不同 Lambda 实例操作同一份内存地址，必须加同步机制，否则必然存在数据竞争。
避免共享可变状态：首选不可变或线程安全容器
最简洁有效的方案是绕过“共享+同步”的复杂性：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
final String fileName = "log.txt"这类不可变局部变量，Lambda 安全捕获后只读，无风险。 - 需要收集结果？别用
ArrayList被多个线程forEach写入。改用Collectors.toList()归约：list.parallelStream().map(s -> s.toUpperCase()).collect(Collectors.toList()) - 真需共享集合？选
ConcurrentHashMap或CopyOnWriteArrayList，而非手动加锁。
必须共享可变变量时：加锁或原子类
当计数、状态标志等必须跨线程更新时，按场景选合适工具：
立即学习“Java免费学习笔记（深入）”；
- 简单计数器 → 用
AtomicInteger：private AtomicInteger counter = new AtomicInteger(0);
Lambda 中调用counter.incrementAndGet()，无锁且原子。 - 复合操作（如先查再改）→ 用
synchronized块或ReentrantLock：Runnable task = () -> { synchronized(this) { count++; } };
注意：锁对象要一致（如用 this 或专用 lock 对象），且覆盖全部临界区。 - 仅需保证可见性（如开关标志）→
volatile：private volatile boolean running = true;
但注意：volatile 不保证running = !running这类读-改-写操作的原子性。
警惕并行流中的副作用陷阱
很多人误以为 parallelStream().forEach(...) 是安全的，其实不然：
- 如果 Lambda 里修改了外部变量（如
list.add(x)）、写文件、发请求等，就是副作用操作，结果不可预测。 - 正确做法是用无副作用的中间操作（
map、filter）+ 终止操作（collect、reduce）来构造纯函数式流程。
