Files.lines() 通过惰性流式读取超大文件避免OOM，关键需用try-with-resources显式关闭、避免sorted/count等全量操作、轻量过滤、显式指定UTF-8编码。
files.lines() 本身不处理“文本变量”，它读取的是磁盘上的文件（path），不是内存中的字符串变量。如果你手头是一个超大的 string 变量（比如几百万字符的 log 内容），那它已经加载进堆内存了——此时再用 files.lines() 没有意义，也解决不了 oom；真正该做的是：避免生成这个大字符串。
所以，问题本质应理解为：如何用 Files.lines() 正确处理超大文本文件（而非变量），从而避免 OOM。核心是“流式 + 惰性 + 及时释放”。以下是关键要点：
必须用 try-with-resources 包裹 Stream
Files.lines() 返回的 Stream 绑定了底层文件通道和 BufferedReader，不关闭就会泄漏文件句柄。尤其在循环处理多个大文件时，很快触发 java.io.IOException: Too many open files。
- ✅ 正确写法：
try (Streamlines = Files.lines(path, StandardCharsets.UTF_8)) { ... } - ❌ 错误写法：
Files.lines(path).filter(...).forEach(...) —— 流对象无引用、无法自动关闭
过滤逻辑要轻量，避免全量消费
Stream 的惰性特性只有在不触发强制终止操作时才生效。以下操作会失去流式优势，等同于把全文读进内存：
-
.collect(Collectors.toList())或.toArray() -
.sorted()（需缓存全部元素） -
.count()（虽不存内容，但仍需逐行扫描到底）
推荐替代方案：
- 只取前 N 行 → 用
.limit(1000) - 找第一个匹配 → 用
.filter(...).findFirst() - 统计但不想扫全 → 改用带状态的
AtomicLong+peek()配合anyMatch()短路退出
避免在 filter 中做高开销操作
每行都执行耗时逻辑，会显著拖慢速度，甚至因 GC 压力间接引发 OOM：
- 不要在 lambda 里反复调用
Pattern.compile()—— 提前编译好Pattern实例复用 - 避免
line.replaceAll()、line.split()生成大量临时对象；如需分词，用预分配的StringBuilder或流式切分 - 跳过空行或注释行优先过滤：
.filter(line -> !line.trim().isEmpty() && !line.startsWith("#"))
显式指定字符集，防止解码异常与隐式跳行
不指定编码时，默认使用 Charset.defaultCharset()，跨平台易出乱码；更严重的是，错误解码可能导致某行解析失败而被跳过（看似少读，实则漏数据）。
- 一律用
Files.lines(path, StandardCharsets.UTF_8) - 若文件是 GBK/ISO-8859-1，明确传入对应 Charset，不要依赖系统默认
本质上，Files.lines() 不是“魔法”，它是把传统 BufferedReader 的手动 while 循环封装成函数式风格，并靠 JVM 的惰性求值和资源契约来守住内存底线。用对了，10GB 日志也能只占几 MB 堆；用错了，一行代码就能埋下泄漏隐患。
