Stream API性能无绝对优劣，取决于数据规模、操作类型等；小数据量用普通流，10万以上CPU密集任务可试并行流；需满足随机访问、无副作用等前提，慎用sorted/distinct，优先IntStream等基本类型流以避免装箱开销。
Stream API 和传统集合操作（如 for 循环、迭代器）没有绝对的“谁更快”，性能边界取决于数据规模、操作类型、硬件环境和具体写法。用对了场景，Stream 可以更简洁且不输性能；用错了，反而拖慢程序。
小数据量（
对少量元素做简单过滤或映射时，for 循环开销极低，无对象创建、无流水线构建、无方法调用栈叠加。Stream 此时要初始化流管道、包装 lambda、触发延迟执行，额外成本明显。尤其当只遍历一次且逻辑简单时，传统方式更直接可靠。
- 避免为 10 个字符串调用
.stream().filter(...).collect(...) - 若只是找一个值，
for+break比findFirst()更轻量（除非后续会扩展成复杂链式） - 注意：JIT 编译后差距可能缩小，但可读性与确定性仍是 for 的优势
中等数据量（1000–10万）：Stream 优势开始显现
当操作变多（比如 filter + map + sorted + collect），Stream 的流水线合并能力发挥作用。JVM 可将多个中间操作融合为单次遍历，避免传统方式中反复新建临时列表。
- 例如：先筛选再转大写再去重 → Stream 可在一次遍历中完成部分逻辑，而手写循环需至少两轮遍历+额外 Set 存储
-
sorted()是有状态操作，代价高，但它只在终端触发前不执行，不会提前拖慢流程 - 此时
anyMatch、findFirst等短路操作能真实跳过剩余元素，比写 break 的 for 更易维护
大数据量（> 10 万）且 CPU 密集：并行流值得尝试
parallelStream() 不是银弹，但对可分割、无共享状态、计算耗时的场景（如解析 JSON 字段、数值计算、正则匹配），能利用多核显著提速。
立即学习“Java免费学习笔记（深入）”；
- 适用前提：数据源支持随机访问（ArrayList 比 LinkedList 合适）、操作无副作用、不依赖顺序
- 慎用
sorted()、distinct()或收集到ArrayList——它们需要归并，削弱并行收益 - 推荐搭配
Collectors.toConcurrentMap或groupingByConcurrent，减少同步竞争
内存与装箱：基本类型流更高效
处理 int/long/double 时，别用 Stream<integer></integer>。装箱拆箱带来 GC 压力和 CPU 开销。
- 用
IntStream.range(0, n)替代Stream.iterate生成索引 - 数值计算优先走
mapToInt→sum()/average()，比泛型流快 2–5 倍 - 避免在流中频繁调用
Integer.valueOf()或new Integer()，JVM 不总缓存
