处理大文件的核心是流式处理、缓冲控制和资源安全。优先用bufferedreader逐行读文本，显式指定编码，缓冲区设64kb或128kb；二进制文件用bufferedinputstream配8kb缓冲；超大文件随机访问可用mappedbytebuffer；统一推荐nio.2的files工具类。
处理大文件（如 10GB+）的核心不是“读得快”，而是“不崩、不卡、不爆内存”。关键在于流式处理、缓冲控制和资源安全，而不是追求单次吞吐量。
优先用 BufferedReader 逐行读文本
对日志、CSV、JSONL 等纯文本大文件，这是最稳、最省内存的方式。它不会把整份文件加载进堆，只保留当前行字符串。
- 显式指定编码（如 StandardCharsets.UTF_8），避免平台默认编码引发乱码或性能抖动
- 缓冲区设为 64KB 或 128KB（如
new BufferedReader(reader, 65536)），比默认 8KB 更少系统调用 - 不用
readLine()后再拼接换行符——若需还原原始格式，改用Files.readAllLines()仅限小文件；大文件请自行缓存分隔逻辑
二进制大文件用 BufferedInputStream + 自定义缓冲块
图片、压缩包、数据库导出文件等必须走字节流。直接用 FileInputStream 效率低，必须套缓冲层。
- 缓冲数组大小建议设为 8192（8KB）或其倍数，与操作系统页大小对齐，减少磁盘寻道
- 始终配合 try-with-resources，防止句柄泄漏导致后续无法删除或重命名文件
- 避免使用
readAllBytes()或readAllLines()——它们会强制全量加载，10GB 文件直接触发 OOM
超大文件随机访问考虑 MappedByteBuffer
当需要频繁跳转读取（如解析固定长度记录、校验某偏移处数据），传统流每次 seek 成本高，可用内存映射提升响应速度。
- 通过
FileChannel.map()获取MappedByteBuffer，操作像数组一样读写指定位置 - 注意：它不等于“把整个文件加载进内存”，而是由 OS 按需分页加载；但映射过大文件仍可能耗尽虚拟地址空间（尤其 32 位 JVM）
- 用完需手动清理（
cleaner.clean()非必须，但长期运行服务建议显式释放）
NIO.2 的 Files 工具类简化路径与异常处理
比起老式 new File(...)，Paths.get() 和 Files 方法更安全、语义更清晰，且内置了权限、符号链接、原子性等现代文件系统特性支持。
- 读文本行：用
Files.lines(path, cs)配合 try-with-stream，支持并行流（但注意线程安全的处理逻辑） - 写文件：用
Files.newBufferedWriter(path, cs, StandardOpenOption.CREATE, StandardOpenOption.APPEND)，明确控制覆盖或追加 - 复制/移动：直接
Files.copy(src, dest, REPLACE_EXISTING)，底层自动选择最优路径（如支持零拷贝时走 sendfile）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
