java中用files.lines()读超大文件需避免oom和资源泄漏：必须用try-with-resources确保流关闭，禁用collect/toarray等全量加载操作，显式指定utf-8编码，且不可调用parallel()。
Java 中用 Files.lines() 配合 Stream 读取超大文本文件，核心在于**避免一次性加载全部内容到内存**，利用流式处理 + 延迟执行 + 及时关闭资源。关键不是“怎么写”，而是“怎么不崩”——尤其要防内存溢出和资源泄漏。
用 try-with-resources 包裹 lines()，确保流自动关闭
Files.lines() 返回的是一个 Stream<string></string>，底层基于 BufferedReader，但不会自动关闭底层通道。如果只调用 forEach 或没消费完就丢弃流，文件句柄可能长期占用，最终触发“Too many open files”错误。
- 必须用 try-with-resources 语法显式管理流生命周期
- 哪怕只是统计行数、找第一行匹配项，也要包裹
- 不能直接写
Files.lines(path).filter(...).findFirst()—— 这样流没被关闭
try (Stream<string> lines = Files.lines(Paths.get("huge.log"), StandardCharsets.UTF_8)) {
Optional<string> firstError = lines
.filter(line -> line.contains("ERROR"))
.findFirst();
// 使用 firstError...
} catch (IOException e) {
// 处理异常
}</string></string>
避免 collect(Collectors.toList()) 或 toArray() 加载全量数据
超大文件（如几 GB 日志）一旦调用 collect(Collectors.toList()) 或 toArray()，等于把所有行读进堆内存，极易 OOM。Stream 的价值就在于“边读边算”，而不是“先读再算”。
- 用
forEach、findFirst、findAny、count、anyMatch等终端操作做“短路处理” - 若需分批处理，可用
limit(n)+ 循环，但注意每次都要新开 stream（Files.lines不支持 reset） - 真要缓存部分数据，用
peek()+ 自定义缓冲器，而非全量收集
指定 Charset，防止乱码和解码异常中断流
Files.lines(path) 默认用系统编码（Windows 是 GBK），而大文件常为 UTF-8。若编码不匹配，某一行解码失败会抛 UncheckedIOException，导致整个流提前终止，且难以定位哪一行出错。
- 始终显式传入
StandardCharsets.UTF_8（或实际编码） - 如需容忍非法字节，可改用
Files.newBufferedReader()+ 自定义CharsetDecoder，但一般不推荐 - UTF-8 是最安全的默认选择，尤其跨平台日志文件
慎用 parallel()，多数场景反而更慢
有人以为加 parallel() 就能加速，但 Files.lines() 返回的流是 顺序流（sequential only），底层基于单线程 BufferedReader，强行并行不仅无效，还可能因竞争导致行为不可预测（如跳行、重复、丢失）。
- 该流不支持并行化；调用
parallel()不报错但无实际并发效果 - 真正需要并行处理大文件，应按块切分（如用 RandomAccessFile 分段读），而非依赖 lines() 的 parallel
- CPU 密集型处理（如每行 JSON 解析+计算）建议在 map 中做，别指望流本身并行
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
