Stream高性能需规避反模式：避免循环中重复创建Stream、慎用peek、并行流须隔离共享状态、防御null和装箱开销。
Stream API 写得“像函数式”不等于写得“高性能”，很多反模式看似优雅，实则埋下性能、线程安全或可维护性隐患。避开它们的关键是理解 Stream 的惰性、一次性、对象开销和并行边界——不是少写几行代码，而是少走弯路。
别在循环里反复创建 Stream
每次调用 list.stream() 都会新建一个流实例，带状态初始化开销；若在 for 循环中反复调用，等于重复构造流水线。
- ❌ 错误示范：
for (int i = 0; i < 1000; i++) {<br> list.stream().filter(...).collect(...);<br>} - ✅ 正确做法：
提前完成过滤/映射等操作，复用结果；或把逻辑移到流外（如预计算条件），避免内层新建流 - ? 小技巧：对固定数据源，可先
stream().collect(Collectors.toList())缓存处理后集合，再多次遍历
慎用 peek，别把它当调试器或副作用入口
peek() 设计本意是“观察”，不是“修改”。它不保证执行顺序（尤其并行流），且每次中间操作都可能触发，容易放大副作用和性能损耗。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ❌ 危险写法：
.peek(user -> user.setActive(true))—— 破坏不可变语义，并行下竞态风险高 - ❌ 低效写法：
.peek(log::info)在百万级流中拖慢 2–3 倍（JMH 实测） - ✅ 安全用法仅限：
开发期加日志（上线前移除）
配合filter做条件性追踪，如.peek(x -> if (x.isLarge()) log.warn("big item: {}", x))
并行流≠自动加速，共享状态必须隔离
并行流默认用公共 ForkJoinPool.commonPool()，若任务阻塞或共享可变容器（如 ArrayList），极易引发数据丢失、扩容异常或线程饥饿。
立即学习“Java免费学习笔记（深入）”；
- ❌ 典型陷阱：
list.parallelStream().forEach(i -> results.add(i * 2))——ArrayList.add()非原子，必出错 - ✅ 替代方案：
用线程安全收集器：collect(Collectors.toConcurrentMap(...))
或改用无状态终端操作：mapToInt(...).toArray()
必要时手动指定线程池：new ForkJoinPool(4).submit(() -> stream.parallel()....).join() - ⚠️ 提醒：小于 10 万元素、IO 密集或含锁操作，串行流通常更稳更快
空值与装箱：从源头掐断 NPE 和 GC 压力
Stream 对 null 不友好，且装箱操作（Integer、Optional）在高频场景下开销显著——原始类型流和防御性检查比“优雅包装”更实在。
- ❌ 两处 NPE 高发：
集合本身为null→list.stream()直接抛异常
集合元素为null→.map(String::toUpperCase)中途炸 - ✅ 防御组合：
集合判空用Optional.ofNullable(list).orElse(Collections.emptyList())
元素判空用.filter(Objects::nonNull)或.map(s -> s == null ? "" : s.toUpperCase()) - ✅ 减少装箱：
数值计算优先用IntStream.range()、mapToInt()，避免Stream<Integer>Optional仅用于语义明确的“存在性链式处理”，简单判空直接if (obj != null)
