Files.lines()分块必须为每次调用单独配try-with-resources——流不关闭会导致句柄泄漏，即使只用skip/limit也需显式关闭；推荐BufferedReader替代以提升分块控制力。
处理大文件分块时，用 Files.lines() 配合 try-with-resources 是最直接、最安全的方式——关键不是“怎么分块”，而是“每一块流都必须独立关闭”。因为 Files.lines() 返回的 Stream<String> 是延迟加载、持有底层文件句柄的资源，**不关闭 = 句柄泄漏**，尤其在循环分块场景下极易触发 “Too many open files”。
分块读取必须为每次 lines() 单独配 try-with-resources
不能把多个 Files.lines() 塞进同一个 try 括号里（语法不允许），也不能只开一次流然后手动切片（Stream 不可重用）。正确做法是：每次分块操作，都新建一个带资源管理的 try 块。
- 例如按行号范围分块处理：每处理 [10000, 20000) 行，就调用一次
Files.lines(path)并包裹在自己的 try 中 - 避免写成：
Stream<String> allLines = Files.lines(...); allLines.skip(...).limit(...).forEach(...);—— 这样整个流没关，且 skip/limit 后无法再安全复用 - 若需跨块共享逻辑，把处理函数抽成方法，但流对象本身必须在 try 内创建、使用、自动关闭
用 Files.lines() + skip + limit 时，仍需完整 try-with-resources
有人误以为 “用了 limit 就只读了部分，句柄会自动释放”，这是错的。只要流没被关闭，文件通道就一直打开。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 正确写法：
lines.skip(10_000).limit(10_000)
.filter(line -> line.contains("WARN"))
.forEach(System.out::println);
} catch (IOException e) {
throw new UncheckedIOException(e);
}</pre>
- 注意：即使只消费了 10,000 行，
lines.close()仍会在 try 块结束时被调用，释放句柄 - 不要在流外保留引用，比如
Stream<String> s = Files.lines(...); ... s.skip(...).limit(...);—— 关闭责任丢失
替代方案：用 BufferedReader 手动分块更可控
当分块逻辑复杂（如按字节偏移、按记录边界拆分）或需反复跳转时，Files.lines() 不够灵活。此时推荐用 BufferedReader，它同样支持 try-with-resources，且可精确控制读取位置。
立即学习“Java免费学习笔记（深入）”；
-
BufferedReader实现AutoCloseable，和FileReader或InputStreamReader组合后，所有层级都会按逆序自动关闭 - 示例：按固定行数分块，每次 new 一个新 BufferedReader（配合
RandomAccessFile或重新打开文件） - 优势：不依赖 Stream 的惰性求值机制，无状态泄漏风险；适合需要 seek、reset 或多轮扫描的场景
别踩这些坑
-
不要复用同一个 Stream：Stream 只能消费一次，第二次 forEach 或 count 会抛
IllegalStateException -
不要在 try 外声明流变量再赋值：如
Stream<String> s; try (s = Files.lines(...)) { ... }—— 编译报错，且破坏语法契约 - 避免 parallelStream + 分块混合：并行流内部可能跨线程持有流引用，关闭时机不可控；分块本身已是串行策略，无需并行化流
-
异常处理要覆盖 IOException：
Files.lines()抛IOException，必须捕获或声明；建议包装为UncheckedIOException向上透传
