files.lines() 表面惰性但易致内存溢出，安全用法是逐行 foreach 处理、避免 sorted/count 等全量操作，必须 try-with-resources 显式关闭并指定 utf-8 编码。
Files.lines() 本身是惰性读取的，但它只是“表面惰性”——一旦你调用 sorted()、collect(Collectors.toList()) 或其他终端操作强制消费全部元素，整个文件内容仍可能被间接加载进内存，尤其在排序或聚合场景下极易触发 OutOfMemoryError。真正安全的关键，是全程保持流的惰性本质，并避免任何需要全量缓存的操作。
只做顺序遍历，不触发全量加载
Files.lines() 返回的是一个 Stream<string></string>，底层基于 BufferedReader，默认按行拉取、即用即弃。只要终端操作是逐行处理（如 forEach、filter + forEach），JVM 不会保留历史行引用，内存占用稳定在几 MB 内。
- ✅ 安全写法：直接处理每行，不累积、不索引
- ❌ 危险写法：调用
count()、max()、reduce()（无初始值）等需遍历全部后才返回结果的操作 - ⚠️ 注意：即使用了
limit(100)，若前面有sorted()，仍会先尝试排序全部数据
规避 sorted() 等全量依赖操作
sorted() 是 Stream 中最典型的内存陷阱。它内部使用 Timsort，必须将所有元素暂存于数组中——对 GB 文件，等于把全部文本行加载进堆内存。
- 替代方案一：改用外部排序（如 Linux
sort命令预处理，再用 Files.lines 读已排序文件） - 替代方案二：分块读取 + 归并（读 N 个文件块 → 各自排序 → 多路归并输出）
- 替代方案三：如果只需 Top-K，用
Stream.collect(Collectors.toCollection(() -> new PriorityQueue(k, comparator)))维持固定大小堆
显式控制资源与编码，防止隐式泄漏
Files.lines() 返回的 Stream 实现了 AutoCloseable，但不会自动关闭底层 FileChannel，除非你用 try-with-resources 包裹。
- ✅ 必须写成：
try (Stream<string> lines = Files.lines(path, StandardCharsets.UTF_8)) { ... }</string> - ⚠️ 编码不匹配会导致乱码或解析中断，特别是含中文/特殊符号时，务必显式指定
StandardCharsets.UTF_8 - ⚠️ 避免在 lambda 中捕获大对象（如外部 List、Map），否则可能阻止整行 GC
配合缓冲与批处理提升吞吐，不增内存压力
单纯惰性读取还不够高效。可通过 Stream.iterate 或自定义 Spliterator 分批处理，每批固定行数（如 1000 行），在批内聚合或转换，再 flush 到磁盘或数据库。
- 例如：用
Collectors.groupingByConcurrent(i -> i / 1000)模拟分块，但注意该方式仍需全量加载，仅作示意；真实推荐用BufferedReader手动循环 + 计数器分批 - 更稳妥做法：放弃 Files.lines()，改用
new BufferedReader(new FileReader(path))，完全掌控读取节奏和 buffer 大小 - SSD 上设置
bufferSize = 8192或更大（如 64KB），可显著减少系统调用次数
