Java Stream API 的资源开销随数据规模、操作类型和环境动态变化，小数据量下常比 for 循环慢，源于流水线构建、Lambda 分配、虚方法调用及数据源分割效率等真实成本；优化需规避重复创建流、慎用并行、优先原始类型流、合理安排操作顺序并选择高效终端操作。
Java Stream API 的资源开销不是固定值，而是随数据规模、操作类型和运行环境动态变化的。小数据量下它常比 for 循环慢，不是因为设计缺陷，而是额外结构和抽象层带来的真实成本。关键在于理解这些开销从哪来、何时显现、怎么规避。
流水线构建与函数调用开销
Stream 每次调用 stream() 都要创建流水线对象，封装迭代器、操作链和状态机。中间操作如 filter 或 map 不立即执行，但会生成 Lambda 实例或方法引用对象——这些在 JIT 热点未稳定前无法内联，每次调用都走虚方法分派路径。而 for 循环是纯字节码跳转，无对象分配、无间接调用。
- 对 100 个元素做简单 sum，Stream 可能多分配 5–10 个临时对象，触发 minor GC 前置开销
- 使用 Integer::sum 比手写 (a, b) -> a + b 更快，因前者是静态方法引用，更易被 JVM 优化
- 避免在循环体内反复调用 list.stream()，应提取为变量或改用 Supplier 缓存
数据源特性与访问方式影响显著
Stream 性能高度依赖底层数据源是否支持高效分割。ArrayList 可 O(1) 定位任意索引，并行流能均匀切片；LinkedList 必须遍历才能取中点，parallelStream() 反而退化成串行甚至更慢。
- 数组或 ArrayList：适合 Stream，尤其并行场景
- LinkedList、TreeSet、自定义 Collection：慎用 parallelStream()，优先考虑传统遍历
- 用 IntStream.range(0, n) 替代 Stream.iterate(0, i -> i + 1).limit(n)，前者无装箱、无对象创建
有状态操作与内存放大效应
sorted()、distinct()、collect(toList()) 这类终端或中间操作会缓存全部或部分数据。例如 sorted() 必须加载所有元素到内存再排序，时间复杂度 O(n log n)，空间复杂度 O(n)；而 for 循环若只找最大值，只需两个 int 变量。
立即学习“Java免费学习笔记（深入）”；
- 大数据集避免链式调用 sorted().filter().map()，可先 filter 缩减规模再 sorted
- 去重优先用 Collectors.toSet() 而非 distinct()，后者需维护内部哈希表且不可控
- 收集结果时，若已知大小，用 Collectors.toCollection(() -> new ArrayList(size)) 减少扩容次数
并行流的真实成本与适用边界
parallelStream() 启动 ForkJoinPool 公共池，任务拆分、工作窃取、结果合并都消耗 CPU 和内存。10 万以下元素、单次加法或字符串拼接这类轻量操作，几乎必然得不偿失。
- 适用并行：CPU 密集型、单元素处理耗时 > 10μs、数据源可随机访问、无共享状态
- 禁用并行：I/O 操作、含 synchronized 块、使用 forEachOrdered、元素间有强顺序依赖
- 可手动控制并行度：ForkJoinPool.commonPool().setParallelism(4)，避免挤占其他模块线程资源
