MappedByteBuffer通过mmap将文件映射到虚拟内存，实现零拷贝随机访问；单次映射≤2GB，超大文件需分段映射，READ_WRITE模式须调用force()刷盘，且需手动释放避免native内存泄漏。
MappedByteBuffer 是 Java NIO 提供的高效文件 I/O 工具，它通过操作系统级别的内存映射（mmap）机制，将文件直接映射到 JVM 的虚拟地址空间，从而绕过传统 IO 的内核态/用户态拷贝，实现超大文件（GB 甚至 TB 级）的低开销随机读写。但它不是“万能加速器”，用法和限制需清晰把握。
核心原理：不是把整个文件加载进堆内存
很多人误以为 MappedByteBuffer 会把文件全部读进 JVM 堆内存——其实完全不是。它只是在虚拟内存中分配一段连续地址空间，并与文件磁盘块建立映射关系；真正读写时由操作系统按需调页（page fault），只将实际访问的文件片段加载进物理内存（Page Cache）。JVM 堆内存不受影响，GC 也不管理这部分内存。
这意味着：
- 可以映射远大于堆内存的文件（如 100GB 文件映射到 2GB 堆的 JVM 中）
- 首次访问某区域可能有轻微延迟（触发缺页中断）
- 不访问 = 不占物理内存，非常节省资源
基本用法：用 FileChannel.map() 创建映射
必须基于 FileChannel，且文件通道需以 READ_ONLY、READ_WRITE 或 PRIVATE 模式打开：
立即学习“Java免费学习笔记（深入）”；
RandomAccessFile raf = new RandomAccessFile("huge.log", "rw");
FileChannel channel = raf.getChannel();
// 映射前 1GB（注意：单次映射不宜过大，通常建议 ≤ 1–2GB）
long size = 1L << 30; // 1GB
MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_WRITE, 0, size);
// 随机写入：跳转到第 500MB 处写 long 值
buffer.position((int)(500L << 20)); // 注意 position 是 int，超 2GB 需分段处理
buffer.putLong(0xCAFEBABEDEADBEEFL);
// 强制刷盘（仅对 READ_WRITE 模式有效）
buffer.force();
⚠️ 关键限制：
- position() 和 limit() 是 int 类型 → 单个 MappedByteBuffer 最大支持约 2GB（Integer.MAX_VALUE 字节）
- 超大文件需“分段映射”：按 1–2GB 切块，每次 map 一段，用完及时清理（见下文）
- 映射后文件不能被其他进程截断或删除（否则可能 SIGBUS 错误）
超大文件处理：分段映射 + 手动管理
对 50GB 日志文件，推荐按固定大小（如 1GB）切片，封装成可寻址的“虚拟缓冲区”：
- 维护一个
Map<Long, MappedByteBuffer>缓存最近使用的段（key = 起始偏移） - 访问 offset 时，计算所属段号：
segmentIndex = offset / segmentSize，再算段内偏移：localPos = (int)(offset % segmentSize) - 用完不再需要的段，显式调用
cleaner.clean()（见下文）释放映射，避免 native memory 泄漏
释放映射的可靠方式（Java 9+ 推荐使用 sun.misc.Unsafe.invokeCleaner() 的封装）：
// Java 9+ 更安全的方式（需反射获取 Cleaner）
Method getCleaner = buffer.getClass().getMethod("cleaner");
getCleaner.setAccessible(true);
Object cleaner = getCleaner.invoke(buffer);
Method clean = cleaner.getClass().getMethod("clean");
clean.invoke(cleaner);
⚠️ 注意：JDK 14+ 移除了 sun.misc.Cleaner 公共 API，生产环境建议用 java.nio.channels.FileChannel.MapMode + 显式 close channel + 控制映射生命周期，或改用 Files.readAllBytes() 分块流式处理（适合只读场景）。
实用建议与避坑点
- 只读优先选 READ_ONLY：性能略优，且不会因 force() 触发写盘抖动
- 写入后务必 force()：否则修改只在 Page Cache，系统崩溃会丢失
- 避免长期持有大量 MappedByteBuffer：每个映射占用虚拟内存和 native memory，过多会导致“Cannot allocate memory”错误（即使物理内存充足）
- Windows 下慎用超大映射：NTFS 对 mmap 支持不如 Linux，易出现映射失败或性能下降
-
替代方案参考：纯顺序读写可用
BufferedInputStream + DataInputStream；结构化大数据考虑memory-mapped Parquet/Arrow格式库
