MappedByteBuffer 加速文件随机访问而非变量存取，适用于大文件中高频局部读、只读或低频写场景；需分段映射防崩溃，复用缓冲区、用 getXXX() 提速，并主动清理防 native 内存泄漏。
MappedByteBuffer 本身不加速“变量存取”，它加速的是对文件内容的随机访问——尤其是当你需要反复读取、跳转访问文件中不同位置的数据（比如数据库索引、日志偏移查找、二进制结构解析）时，它能绕过系统调用和内核缓冲区拷贝，让字节访问接近内存数组的速度。但它不是用来优化 Java 局部变量或对象字段访问的工具。
真正能靠 MappedByteBuffer “加速”的，是对文件数据的低开销、高局部性访问。关键不在“映射”，而在“怎么用”。
一、明确适用场景：什么情况下真能变快？
- ✅ 文件很大（GB 级），但你只频繁访问其中一小块（如头部元信息、固定偏移的记录块、稀疏索引）
- ✅ 访问模式是随机读（非顺序扫描），且具有局部性（比如反复查某几个 offset）
- ✅ 文件只读或写入频率极低，且可接受 OS 异步刷盘（READ_WRITE 模式下 force() 成本高）
- ✅ 你已排除其他更稳方案：如
Files.readAllBytes()+ 堆内缓存（FileChannel.read() 配合DirectByteBuffer池（顺序处理）
❌ 不适合：
- 全量顺序扫描 100GB 日志（此时
transferTo或流式read()更省资源） - 高频小粒度写 + 强一致性要求（force() 同步落盘会拖慢）
- 多线程高频创建/丢弃映射（易触发
max_map_count耗尽或 native 内存泄漏）
二、正确分段映射 >2GB 文件（避免崩溃）
Java 的 FileChannel.map() 接口虽接受 long size，但 MappedByteBuffer 内部仍基于 int 索引（position/limit），因此单次映射上限为 2,147,483,647 字节（≈2GB）。超限会抛 IllegalArgumentException。
安全做法：
- 按需计算每段大小：
long segmentSize = Math.min(2L * 1024 * 1024 * 1024, remaining); - 使用
channel.map(MapMode.READ_ONLY, offset, (int) segmentSize)
（注意强制转int，且segmentSize ≤ Integer.MAX_VALUE） - 处理完当前段后，丢弃引用；如长期运行服务，建议显式清理（见下文）
三、提升实际访问速度的关键细节
-
避免重复创建映射：对固定区域（如文件头 4KB），复用同一个
MappedByteBuffer，不要每次访问都 map/unmap -
利用
getXXX()直接读基本类型：int magic = buffer.getInt(0); // 比 get(byte[]) + ByteBuffer.wrap() 快得多 long timestamp = buffer.getLong(8);
-
预加载热区（可选）：调用
buffer.load()提示 OS 提前将页载入物理内存（不保证常驻，但减少首次缺页延迟） -
确认是否已加载：
buffer.isLoaded()返回false说明尚未触发缺页，后续首次访问才有延迟
四、防止 native 内存泄漏（最易被忽略）
JVM 不主动释放 MappedByteBuffer 占用的 native 映射资源。GC 触发 Cleaner 是异步且不可控的，尤其在压力下可能堆积大量未释放映射，最终导致：
- Linux 报
IOException: Cannot allocate memory（max_map_count耗尽） - 进程 RSS 持续上涨，甚至被 OOM Killer 杀死
稳妥释放方式（JDK 9+）：
private static void unmap(MappedByteBuffer buffer) {
if (buffer == null || !buffer.isDirect()) return;
try {
Method cleanerMethod = buffer.getClass().getMethod("cleaner");
cleanerMethod.setAccessible(true);
Object cleaner = cleanerMethod.invoke(buffer);
if (cleaner != null) {
Method cleanMethod = cleaner.getClass().getMethod("clean");
cleanMethod.invoke(cleaner);
}
} catch (Exception ignored) {}
}⚠️ 注意：该方式依赖内部 API，JDK 14+ 中 Cleaner 已迁移至 jdk.internal.ref.Cleaner，反射需适配；生产环境建议配合监控 cat /proc/<pid>/maps | grep '\.bin' | wc -l</pid> 控制映射数。
不复杂但容易忽略
