Java Stream API内存优化关键在于控制对象驻留数量：避免sorted()等全量加载终端操作，前置filter减少中间对象，优先使用原始类型流和并发收集器，并谨慎使用parallelStream()。
Java Stream API处理大规模对象集合时，内存问题主要来自终端操作的全量加载行为和中间操作的设计不当。关键不是“能不能用Stream”，而是“怎么用才不把堆撑爆”。
警惕高内存消耗的终端操作
sorted()、collect(Collectors.toList())、toArray() 这类操作默认会将全部数据一次性载入内存。哪怕源集合本身是懒加载的（如 Files.lines()），一旦接上 sorted，就会触发整条数据流的预读和排序建堆——600MB文本文件排序失败，往往就卡在这一步。
- 如果只是找 Top N，改用 limit(n) + sorted(Comparator.reverseOrder())，并确保 sorted 在 limit 之后（否则仍全量排序）
- 若必须分组聚合，避免 groupingBy 直接映射大列表；可先用 groupingByConcurrent 配合 toSet 或 counting，再按需展开值集合
- 对超大集合转数组，优先考虑 toArray(IntFunction) 形式指定数组类型，避免无参 toArray() 的二次扩容
让中间操作真正“懒”起来
filter、map 等中间操作虽惰性执行，但顺序不合理仍会放大内存压力。比如先 map 再 filter，可能为大量后续会被筛掉的对象提前创建了新实例。
- 把过滤条件尽可能前置：filter → map → flatMap 比 map → filter 更省内存
- 避免在 map 中做重量级对象构造；如需转换，优先用轻量标识或延迟初始化字段
- 对嵌套结构，用 flatMap 替代 map + 循环 add，减少中间集合临时驻留
用对流类型，避开装箱与冗余对象
处理数值型字段时，Stream<Integer> 是常见陷阱。每次 int 装箱成 Integer，100 万条记录就多出百万级对象，GC 压力陡增。
立即学习“Java免费学习笔记（深入）”；
- 原始类型场景一律用 IntStream / LongStream：如 list.stream().mapToInt(Item::getId) 后接 sum() 或 summaryStatistics()
- 字符串批量处理慎用 parallelStream() + split，容易因 String.substring 共享底层数组导致内存无法释放；改用 Pattern.compile(...).splitAsStream() 更可控
- 自定义对象流中，若仅需某几个字段参与计算，先 map 成轻量 record 或简单数组，而非保留完整对象引用
并行流不是银弹，得看数据特征
parallelStream() 对 CPU 密集型、无状态、可分割的数据（如 ArrayList）有效；但对 LinkedList、Stream.iterate 或含 limit/findFirst 的链路，反而增加线程调度和合并开销，还可能引发 OOM。
- 确认数据源支持高效分割：ArrayList、数组、IntRange 可；LinkedList、Spliterators.spliteratorUnknownSize() 不建议并行
- 避免在 parallelStream() 中使用非线程安全容器（如 ArrayList.add）；必须收集时用 Collectors.toCollection(() -> new CopyOnWriteArrayList())
- 对 I/O 密集型操作（如远程调用、文件读取），并行流常因阻塞拖垮线程池，应改用 CompletableFuture 编排
不复杂但容易忽略：内存优化的本质是控制驻留对象的生命周期和数量，而不是堆大小。Stream 写得再“函数式”，只要终端操作拉满、中间操作乱序、类型选错，照样 OOM。
