核心是流式读取、及时丢弃、不累积引用：禁用files.readalllines()等全量加载，改用bufferedreader（8kb–64kb缓冲）或files.lines()配try-with-resources，避免引用滞留与强制落地操作。
处理大文本文件时的内存溢出问题，核心不是“加内存”，而是避免把整份内容塞进堆里。关键在流式读取、及时丢弃、不累积引用。
用带缓冲的逐行流代替全量加载
别用 Files.readAllLines() 或 Files.readString()，它们会一次性把全部文本转成字符串列表或大字符串，极易触发 OutOfMemoryError。改用 Files.lines() 配合 try-with-resources，确保每行只在当前处理时存在：
- 用
BufferedReader搭配 8KB–64KB 缓冲区（如new BufferedReader(new FileReader(f), 8192)），减少系统调用次数 - 优先考虑 Apache Commons IO 的 LineIterator，它内部不缓存历史行，且自动关闭流
- 如果必须用 Stream API，避开
.sorted()、.collect(Collectors.toList())等强制落地内存的操作
处理逻辑中严防引用滞留
很多 OOM 发生在“处理完却没放手”：比如把每行 add 进 ArrayList、拼到 StringBuilder 里、或塞进静态 Map。只要业务不要求回溯，就该让对象尽快不可达：
- 逐行处理后，不保留该行引用；避免写
list.add(line)后长期持有 - 日志打印大文件路径时，别顺手 log 整行内容；监控埋点也别序列化原始字符串
- 若需中间聚合（如统计词频），用固定大小的 Map + LRU 或软引用控制容量，而非无界缓存
配合 JVM 和部署环境做兜底
代码写对是基础，但上线后还需检查环境是否暗中放大压力：
- 确认
-Xmx设置合理（如 2g–4g），但别盲目堆高——治标不治本 - 检查 Nginx 等反向代理是否开启了 gzip 压缩，它可能缓冲整个响应体再发送，导致后端内存+代理内存双重承压
- 启用堆转储：加 JVM 参数
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/，OOM 后可直接用 MAT 分析谁占了最多内存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
