Java Stream处理大文件OOM主因是终端操作打破惰性，强制全量加载；应避免sorted/collect全量驻留，优先filter前置、用外部排序、分批处理、显式关闭流并边读边写。
Java 中用 Stream API 处理大文件时，内存溢出（OOM）几乎都源于一个错误假设：「Stream 是懒加载的，所以一定省内存」。其实不然——终端操作会打破惰性，强制加载、驻留、合并大量数据。关键不是“用不用 Stream”，而是“在哪停、怎么停、停了之后怎么走”。
别让 sorted() 或 collect() 把整份文件拖进堆里
像 Files.lines(path).sorted().forEach(...) 这类写法，哪怕文件只有 500MB，也会在排序阶段把全部行读入内存并构建比较结构，极易触发 OutOfMemoryError: Java heap space。同理，collect(Collectors.groupingBy(...)) 在键值量大时会让 Map 持续膨胀，合并阶段更可能雪上加霜。
- 能不排序就不排：若只需取前 N 条，改用
limit(N)；若必须排序且文件超大，放弃内存排序，改用外部归并（如分批排序写临时文件，再归并） - 分组优先用并发收集器：
Collectors.toConcurrentMap()或groupingByConcurrent()，避免多线程各自建 Map 后再 merge - 过滤务必前置：把
filter()放在map()和sorted()前面，早筛早省，减少后续操作的数据基数
用对流源，避开 readAll* 和无节制的 lines()
Files.readAllLines()、Files.readAllBytes() 是典型“全量陷阱”，几 GB 文件一调就崩。而 Files.lines() 虽是惰性流，但一旦终端操作触发全量消费（比如 count()、collect(toList())），效果等同于全量加载。
- 文本文件首选
BufferedReader.readLine()配合 try-with-resources，每次只持有一行字符串 - 若坚持用
Files.lines()，必须确保终端操作支持短路（如findFirst()、anyMatch()）或配合limit(n)+ 分页逻辑 - 二进制文件别碰 Stream<String>，直接用
FileInputStream+byte[8192]循环读块，处理完即丢
并行流不是万能解药，反而可能是 OOM 加速器
parallelStream() 在分组、聚合、reduce 场景下，常因各线程生成局部中间结果 + 合并逻辑低效，导致堆内对象暴增。尤其当数据源是 LinkedList 或自定义低效 Spliterator 时，分割过程本身就会复制数据。
立即学习“Java免费学习笔记（深入）”；
- 数据源优先选 ArrayList、数组或 IntStream.range，避免 LinkedList、HashSet 等分割成本高的结构
- 显式加
unordered()消除顺序约束，让limit、groupingBy等操作并行更高效 - 超大数据集不要一股脑 parallelStream()，可先
subList分块，每块单独并行处理，最后轻量合并 - 收集器指定初始容量：
toCollection(() -> new ArrayList(estimatedSize))，防扩容复制开销
该放手时就放手：及时写出、清空、释放
流式处理 ≠ 内存安全。常见误区是“流关了，内存就干净了”，但若你在 lambda 里把每一行 add 进了一个全局 List，或用 ByteArrayOutputStream 缓存所有字节，那流关了也没用——引用还在，GC 不会回收。
- 边读边写：逐行解析后直接写入临时文件或数据库，不累积中间集合
- ByteArrayOutputStream 达到阈值（如 10MB）就
writeTo(outputStream)并reset() - 避免闭包捕获大对象：lambda 中不要引用整个文件对象、大缓存 Map 或未关闭的流
- 资源务必显式关闭或用 try-with-resources，防止文件句柄和缓冲区长期驻留
