应避免在Stream中使用有状态的lambda表达式，核心是坚持无副作用和不可变上下文；需禁用forEach累积、禁用外部可变对象、改用collect/map/filter等纯函数式操作。
避免在 Stream 中使用有状态的 lambda 表达式，核心是守住“无副作用”和“不可变上下文”这两条线。Stream 的设计哲学是函数式、声明式、可并行——一旦 lambda 内部修改外部变量或依赖可变状态，就破坏了这一前提，轻则结果错乱，重则并发崩溃。
不捕获可变的局部变量
Java 要求 lambda 捕获的局部变量必须是“等效 final”的，但很多人误以为只要编译通过就安全。实际风险在于：捕获的是引用，而引用指向的对象本身可能被多处修改。
- ❌ 错误写法：用 ArrayList 或 StringBuilder 在 lambda 里累积结果
List<String> result = new ArrayList<>();
stream.forEach(s -> result.add(s.toUpperCase())); // 违反函数式原则，且 forEach 不保证顺序，并发流下线程不安全
- ✅ 正确做法：用 collect() 替代，让 Stream 自己管理中间状态
List<String> result = stream.map(String::toUpperCase).collect(Collectors.toList());
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 注意：collect 是终端操作，专为聚合设计；它内部使用线程安全的合并策略（如并发流中自动调用 combiner），无需你手动维护状态
不依赖外部可变对象（如单例、静态字段）
即使 lambda 没捕获局部变量，如果它调用了某个共享对象的非线程安全方法（比如一个非 synchronized 的计数器），依然属于“有状态”。
- ❌ 错误写法：在 lambda 中调用全局计数器的 increment()
AtomicInteger counter = new AtomicInteger(0);
stream.map(s -> { counter.incrementAndGet(); return s.length(); }).collect(...);
- ✅ 正确做法：把状态计算移到 Stream 外，或改用无状态方式表达逻辑
- 例如，需要统计长度大于 5 的字符串个数？直接用 filter().count()，而不是靠外部变量累加
不滥用 forEach 做副作用操作
forEach 是为“消费”设计的，不是为“构建”或“累积”。它不承诺执行顺序（尤其在并行流中），也不提供组合能力。
- ❌ 避免：用 forEach 更新 Map、写日志计数、触发外部 API 调用（除非明确接受非顺序、不可重试）
- ✅ 替代方案：
- 需要转换 → 用 map()
- 需要筛选 → 用 filter()
- 需要聚合 → 用 reduce() 或 collect()
- 真要执行副作用（如打印、调试）→ 明确用 peek()（仅用于调试），或回到传统 for 循环（语义清晰、可控）
警惕“看似无状态”的陷阱
有些 lambda 看似只读，实则隐含状态。典型例子是捕获了随机数生成器、时间戳、或未同步的缓存实例。
- ❌ 示例：捕获 Random 实例并在 lambda 中 nextInt() —— Random 本身是非线程安全的
- ✅ 解法：用 ThreadLocal<Random>，或改用 SecureRandom（线程安全），或干脆用 Stream 自带的 generate(Supplier) 配合无状态 Supplier
