Java NIO FileChannel 映射文件过大时怎么控制内存占用

遇到几十 GB 的日志、索引或归档文件时，直接把整个文件交给 FileChannel.map 往往会先撞上参数上限，再把地址空间和文件页缓存的压力放大。更稳妥的做法是把文件切成固定窗口，每次只保留当前窗口，必要时再保留一个很小的跨边界缓冲。

经典 FileChannel.map 返回的 MappedByteBuffer，单次映射大小不能超过 Integer.MAX_VALUE。控制内存的关键不是让映射大小等于文件大小，而是同时限制窗口大小、活跃映射数量，并且不要主动把所有窗口 load() 进物理内存。

FileChannel.map 为什么会让大文件读取失控

map 建立的是文件区域到内存的映射，返回对象是直接缓冲区，并不是把文件内容复制到 Java 堆里的 byte[]。但这不代表可以无限映射：经典重载的 size 最大是 Integer.MAX_VALUE，而且映射在对应的 buffer 被垃圾回收前仍然有效，关闭创建它的 channel 也不会立刻让映射失效。

真正容易被忽略的是三个量：文件的逻辑大小、进程的虚拟地址范围，以及当前被操作系统带入物理内存的页。映射 20 个 256 MB 窗口不等于立即占用 5 GB 物理内存，但如果代码把这些 buffer 放进集合，或者对每个 buffer 调用 load()，页缓存、地址空间和回收压力都会一起上升。

用固定窗口限制单次映射和活跃引用

顺序读取时可以先用 256 MB 作为窗口起点。窗口大小不是越大越好：窗口太小会增加 map 次数，太大则会让并发扫描的地址空间和页压力变得难以预测。下面的写法只保留当前窗口，且最后一个窗口按文件剩余长度收缩。

import java.io.IOException;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

static final long WINDOW_SIZE = 256L * 1024 * 1024;

static void scan(Path path) throws IOException {
    try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
        long fileSize = channel.size();
        for (long offset = 0; offset 

这个上限同时解决了两个问题：单个 MappedByteBuffer 不会超过 API 允许的容量，活跃映射也不会随着文件大小线性增长。若任务是并发扫描多个文件，还要把“每个任务一个窗口”乘进预算，而不是只看单个窗口。

窗口边界不能切断业务记录

字节窗口和业务记录不是同一个边界。文本扫描时，一行可能在窗口 A 的最后几个字节开始，在窗口 B 的开头结束；定长二进制记录也可能被切成两段。窗口切换后直接把两段分别交给解析器，常见结果是半条记录、乱码或校验失败。

解决办法是给解析器保留一个很小的 carry-over：当前窗口遇到未闭合记录时只暂存边界片段，下一窗口到达后先拼接，再交给完整记录解析器。这个缓冲的大小由单条记录上限决定，与整个映射窗口无关。

不要用 load 代替内存控制

MappedByteBuffer.load() 是“尽力让内容驻留物理内存”的提示，不是释放旧窗口的手段。顺序读取通常让操作系统按访问模式调页即可；只有在有明确的随机访问基准和内存预算时，才值得单独评估 load() 或 isLoaded()。读写映射还要根据业务决定何时调用 force()，它解决的是持久化可见性，不是窗口大小。

如果运行环境是 Java 22 或更高版本，并且需要更清晰的映射生命周期，可以考虑带 Arena 的 FileChannel.map 重载，返回 MemorySegment，在可关闭的 arena 结束时解除映射。它适合已经采用 Foreign Function & Memory API 的代码；老项目只为追求“立即释放”而整体迁移，通常不如先把窗口和引用关系收紧。

相关问题

窗口设成 2 GB 会更快吗？

不一定。吞吐还受访问局部性、存储设备和并发数影响；先从 128 MB 或 256 MB 做基准，再看缺页和延迟变化。

关闭 FileChannel 后映射会消失吗？

不会。经典映射的有效期与返回的 buffer 绑定，channel 关闭不等于立即解除映射，所以更要避免长期保存 buffer 引用。

什么时候不该用 map？

文件只有几十 KB、访问很零散，或记录解析本身已经有成熟的流式背压时，普通 read(ByteBuffer) 可能更简单；官方文档也提醒，映射小数据可能比常规读写更昂贵。

参考：Oracle Java SE 25 FileChannel、Oracle Java SE 25 MappedByteBuffer。