files.lines配合stream是java处理海量文本行数据最轻量可控的方式，需用try-with-resources显式关闭流、避免全量终止操作、优先廉价过滤、复用pattern、显式指定编码与路径。
Files.lines 配合 Stream 是 Java 处理海量文本行数据最轻量、最可控的方式——它不把文件全读进内存，而是按需拉取每一行，真正实现“边读边算”。关键不在用不用 Stream，而在怎么用才不踩坑。
必须用 try-with-resources 显式管理资源
Files.lines 返回的 Stream 绑定了底层文件句柄和缓冲区，不是普通集合流。JDK 8 不支持自动关闭，只调用 .close() 或丢弃引用都会泄漏句柄，运行久了直接报 Too many open files。
- ✅ 正确写法：用 try 声明并持有 Stream 引用，确保异常或正常执行后都关闭
- ❌ 错误写法：Files.lines(path).filter(...).forEach(...) —— 流对象无变量引用，无法关闭
- ⚠️ 注意：不要在 lambda 里捕获可变外部变量（如 int count = 0），改用 AtomicInteger 或 peek + AtomicLong 累计
保持惰性，避开全量操作陷阱
Stream 的优势只在“没触发终止操作”时存在。一旦调用 .count()、.sorted()、.collect() 或 .toArray()，就会强制遍历全部行，等于放弃流式优势，大文件照样 OOM。
- 想取前 N 行？用 .limit(N)，不加载后续内容
- 找第一个匹配项？用 .filter(...).findFirst()，命中即停
- 需要统计但怕扫太慢？用 .peek(line -> counter.incrementAndGet()).anyMatch(predicate) 实现短路+计数
- 避免 .map(line -> heavyParse(line)) 这类耗时操作，尤其别在 map 里反复 new Pattern 或 split 生成大量临时对象
逐行解析要轻量，优先做廉价过滤
真正影响吞吐的是每行处理逻辑的开销。先筛掉明显无关内容，再做结构化解析，能显著减少计算压力。
- 开头就 filter 掉空行、注释行、无效前缀：.filter(line -> !line.trim().isEmpty() && !line.startsWith("#"))
- 字段提取优先用 String.indexOf("/") + substring，比 line.split(" ") 更省内存
- 正则匹配务必复用 Pattern.compile(...) 的实例，别每次 new
- 若需转成对象（如 LogEntry），用构造器直接接收原始字符串，避免中间 List 或 Map
编码与路径必须显式指定，别信默认值
不传 Charset 就用系统默认编码，跨环境极易乱码；不规范构造 Path 可能导致路径解析失败或安全问题。
- 一律用 Files.lines(Paths.get("/path/to/file.log"), StandardCharsets.UTF_8)
- GBK 或 GB2312 文件，明确传 Charset.forName("GBK")，别靠 guess
- 路径优先用 Paths.get() 或 Path.of()，避免字符串拼接引入平台差异或注入风险
- 如果文件是日志且含时间戳，可配合 DateTimeFormatter.parseBest() 做柔性解析，不因单行格式异常中断整流
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
