MappedByteBuffer 并非将整个大文件加载进内存，而是建立虚拟地址与文件的映射，按需分页加载；超2GB文件须分块映射，注意 max_map_count 限制；三种模式需按权限和语义正确选用；释放依赖 Cleaner 或反射，JVM GC 不直接管理。
为什么 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()刷盘后显式丢弃引用，避免高频创建
真正麻烦的不是映射本身，而是你没法精确知道操作系统什么时候真正解除了 mmap —— 尤其当文件正被其他进程读写时，内核可能延迟回收。这点在容器环境里更容易暴露，别指望“手动清理”就能 100% 立刻释放 fd 和虚拟内存。
