流操作因惰性求值特性，终端操作触发时需全量加载数据至内存，叠加中间操作对象累积、装箱拆箱开销及分支重复遍历，显著放大内存压力，远超传统迭代方式。
因为流操作（Stream）在默认情况下是惰性求值的，但一旦触发终端操作（如 collect()、forEach()、toArray()），JVM 就必须将整个数据集加载进内存完成计算——尤其当源头本身就是大集合或未分页的数据库结果时，这种“全量拉取 + 全量处理”的模式会直接压垮堆空间。
流操作隐式放大内存压力
Stream API 表面简洁，背后却容易引入三重开销：
- 中间操作链不执行，但会累积状态：filter、map、sorted 等操作本身不消耗内存，但每个操作都生成新的 Stream 对象并持有上游引用；链越长，对象图越复杂，GC 压力越大
-
终端操作常触发全量 materialization：比如
stream.collect(Collectors.toList())会新建 ArrayList 并把全部元素复制进去；stream.toArray()同样要分配与源数据等长的新数组 -
装箱/拆箱泛滥：对基本类型数组（如
int[]）调用Arrays.stream(arr)得到的是IntStream，但若误写成Stream.of(arr)或Arrays.asList(arr)，就会把整个数组当作单个 Object 包装，或引发Integer[]的批量装箱，内存占用翻数倍
分支体中叠加多层流加剧问题
数据清洗常含条件分支（如按字段类型分流、按业务规则分组），若每个分支都独立构造完整 Stream 流程，会出现：
- 同一原始数据被多次遍历：比如先 filter 分出 A 类，再 filter 分出 B 类，底层仍是两次全量扫描 + 两次中间对象构建
- 分支间无法共享中间状态：无法像传统 for 循环那样边遍历边分类，导致冗余计算和重复内存驻留
- lambda 捕获外部大对象：分支逻辑若引用了清洗前的原始 List 或 Map，该集合会被整个闭包持住，延长生命周期，阻碍 GC
对比传统方式更耗资源
原生数组或 Iterator 驱动的清洗逻辑，天然支持“边读边洗、边洗边吐”，而流式写法容易脱离这个节奏：
- 用
for (int i = 0; i 处理 <code>double[]，全程只占几个局部变量空间 - 用
Iterator<record></record>配合while (it.hasNext())，每次只加载一条记录，内存恒定 - 而
list.parallelStream().filter(...).map(...).collect(...)可能瞬间申请数百万对象、数 GB 堆空间，且并行流还会额外创建线程池和分割任务队列
真正轻量的替代思路
不是禁用 Stream，而是控制它的作用域和形态：
- 对超大数据源，改用
Stream.iterate或自定义Spliterator实现按需供给，避免一次性加载 - 清洗逻辑尽量下沉到 record 级别：用单次遍历 + if-else 分支完成所有转换，而不是为每类规则建一个 Stream
- 必要时用
try-with-resources包裹流式 IO（如Files.lines(path)），确保底层缓冲区及时释放 - 基础数值运算坚持用原生数组 + IntStream.of() / DoubleStream.of()，避开
List<integer></integer>这类高开销容器
