怎么利用MappedByteBuffer将大文件直接映射到物理内存-java教程-PHP中文网

MappedByteBuffer 并非将整个大文件加载进内存，而是建立虚拟地址与文件的映射，按需分页加载；超2GB文件须分块映射，注意 max_map_count 限制；三种模式需按权限和语义正确选用；释放依赖 Cleaner 或反射，JVM GC 不直接管理。

怎么利用mappedbytebuffer将大文件直接映射到物理内存

为什么 `MappedByteBuffer` 不等于“把整个大文件加载进内存”

很多人一看到“内存映射”就默认文件内容会立刻全部进入物理内存，其实不是。MappedByteBuffer 只是建立虚拟地址空间与文件的映射关系，真正读写时才按需触发缺页中断，由操作系统把对应页从磁盘拉入物理内存（lazy loading）。这意味着：即使映射一个 20GB 的文件，RSS（常驻内存）初始可能只有几 MB；但随机访问分散区域时，可能引发大量缺页，反而拖慢性能，甚至触发 OOM。

关键判断：如果你需要顺序扫描、局部热点访问，MappedByteBuffer 很合适；如果要做全量遍历或频繁跨段跳转，传统 FileChannel.read() + 堆外缓冲池可能更稳。

怎么安全创建 `MappedByteBuffer` 避免 `IOException` 或 `OutOfMemoryError`

常见错误是直接用 Integer.MAX_VALUE 当 size 参数，或对 >2GB 文件不拆分。JVM 在 64 位系统上虽支持大地址空间，但 FileChannel.map() 的 size 是 long，而 MappedByteBuffer 的 limit()/position() 方法仍基于 int，导致单次映射不能超过 2GB（即 0x7FFFFFFF 字节）。

对超 2GB 文件，必须分块映射：每次 map() 一个 ≤2GB 的 ByteBuffer，用 position 控制起始偏移
确保文件打开时使用 FileChannel.open(path, StandardOpenOption.READ)，写入场景加 StandardOpenOption.WRITE，否则 map() 抛 NonReadableChannelException
Linux 下注意 /proc/sys/vm/max_map_count，默认常为 65530，映射太多小段会耗尽，可临时调高：sudo sysctl -w vm.max_map_count=262144

`MappedByteBuffer` 的三种模式：何时用 `READ_ONLY`、`READ_WRITE`、`PRIVATE`

模式选错会导致数据不一致或权限异常。比如用 READ_WRITE 映射只读文件，会抛 IOException("Access is denied")（Windows）或 IOException("Permission denied")（Linux）；用 PRIVATE 却想让修改落盘，结果白改。

READ_ONLY：最安全，适合日志分析、配置读取；映射后文件被其他进程修改，本进程读到的是映射时刻快照（取决于 OS 页面缓存策略）
READ_WRITE：修改 buffer 内容 = 直接修改文件内容（脏页由 OS 异步刷盘），需确保文件有写权限且未被锁死
PRIVATE：写操作触发写时复制（COW），buffer 可改，但不回写文件，也不影响其他映射者 —— 适合做临时编辑再另存，但注意 COW 会额外占用物理内存

释放映射和避免内存泄漏的硬办法

MappedByteBuffer 不受 JVM 垃圾回收直接管理，System.gc() 也不能保证立即释放底层 mmap 资源。尤其在频繁映射/取消映射场景（如微服务处理大量上传文件），容易出现 java.io.IOException: Cannot delete file 或 “Too many open files”。

Java 9+ 推荐用 Cleaner 注册清理动作：cleaner.register(buffer, () -> unmap(buffer))，其中 unmap() 调用反射获取 sun.misc.Cleaner 并 clean
Java 8 及以前只能靠反射调用 DirectByteBuffer.cleaner().clean()，但该 API 不稳定，不同 JDK 版本字段名可能变化（如 OpenJDK 8 是 cleaner，Zulu 可能叫 att）
更稳妥的做法是：复用固定数量的映射段（例如最多 4 个 1GB 段），用完 force() 刷盘后显式丢弃引用，避免高频创建