Java 中使用 mmap 技术简介
Java 中 mmap（Memory-Mapped File，内存映射文件）指的是将文件（或文件的一部分）直接映射到进程的虚拟地址空间，让程序像操作内存数组一样读写文件，而不需要显式地调用 read/write 系统调用。
这种方式在高性能 I/O 场景下非常有用，尤其适用于大文件随机读写、日志追加、数据库索引文件、共享内存等场景。
Java 中实现 mmap 的主要方式（2025–2026 年主流做法）
| 方式 | 核心类/包 | 是否原生支持 | 性能 | 使用难度 | 典型场景 | 推荐程度（2026 年） |
|---|---|---|---|---|---|---|
| MappedByteBuffer | java.nio.channels.FileChannel | 原生支持 | 最高 | 中等 | 大文件随机读写、零拷贝 | ★★★★★（首选） |
| sun.nio.ch.DirectBuffer / Unsafe | sun.misc.Unsafe / jdk.internal.misc.Unsafe | 非公开 API | 极高 | 高 | 极致性能、需要 off-heap 操作 | ★★★☆（谨慎使用） |
| Chronicle-Bytes / MapDB | 第三方库 | 封装 mmap | 高 | 低 | 持久化队列、KV 存储 | ★★★★（业务友好） |
| io.github.alexarchambault.jmmap | 第三方（较新） | 封装 mmap | 高 | 中等 | 跨平台、简单 API | ★★★（小众） |
1. 最常用方式：MappedByteBuffer（推荐入门 & 生产首选）
import java.io.RandomAccessFile;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.channels.FileChannel.MapMode;
public class MmapExample {
public static void main(String[] args) throws Exception {
try (RandomAccessFile raf = new RandomAccessFile("largefile.dat", "rw");
FileChannel channel = raf.getChannel()) {
// 映射整个文件（或指定大小）
long fileSize = channel.size();
// READ_WRITE / READ_ONLY / PRIVATE
MappedByteBuffer buffer = channel.map(
MapMode.READ_WRITE,
0, // 起始位置
fileSize // 映射长度（可小于文件大小）
);
// 像操作 byte[] 一样使用
buffer.put(0, (byte) 65); // 写
byte b = buffer.get(1024 * 1024); // 读
// 强制刷盘（可选，性能敏感时慎用）
buffer.force();
// 建议：映射完成后尽快释放资源（但 MappedByteBuffer 本身不 close）
// 依赖 channel 关闭或 JVM 退出才会真正 unmap
}
}
}关键点总结：
- 零拷贝：数据不经过用户态缓冲区，直接从内核页缓存到用户进程地址空间
- 延迟写：写操作通常只是修改页缓存，真正落盘由 OS 决定（可通过
force()强制） - 内存开销：映射多大就占用多少虚拟地址空间（不是物理内存）
- 页故障：第一次访问对应页时会触发 page fault，由 OS 从文件中加载（读放大可能存在）
2. 常见使用场景 & 典型大小
| 场景 | 映射大小建议 | 是否需要 force() | 注意事项 |
|---|---|---|---|
| 大文件随机读 | 几 GB ~ 几十 GB | 否 | 适合日志分析、索引文件 |
| 高性能日志追加（append） | 128MB–1GB 切片映射 | 否（定期 force） | 避免映射整个超大文件 |
| 共享内存（进程间通信） | 几 MB ~ 几 GB | 视情况 | 多个 JVM 映射同一文件实现 IPC |
| KV 存储 / 嵌入式数据库 | 按需分段映射 | 定期 | Chronicle-Queue、MapDB 常用此方式 |
| 极致低延迟写 | 小块映射 + Unsafe | 否（异步刷盘） | 金融、交易系统常见 |
3. 踩坑 & 注意事项（2026 年仍常见问题）
- MappedByteBuffer 无法主动 unmap
只能依赖 FileChannel 关闭或 JVM 退出。
→ 解决方案：使用分段映射 + 定时清理旧映射，或借助第三方库封装。 - 32 位 JVM 地址空间限制
32 位 JVM 虚拟地址只有 ~4GB，映射大文件会失败。
→ 现在基本都用 64 位 JVM，已基本不是问题。 - 内存使用统计不准
MappedByteBuffer占用的是虚拟内存，不是堆内存，Runtime.freeMemory()看不到真实压力。 - Page Fault 导致延迟毛刺
冷启动时第一次访问大范围会导致大量 page fault。
→ 建议预热：顺序遍历一次映射区域。 - 跨平台行为差异
Windows 和 Linux 对 mmap 的写回策略、unmap 时机不同，生产环境要充分测试。
4. 推荐现代替代 / 封装库（2026 年主流）
- Chronicle-Bytes / Chronicle-Queue：最成熟的 mmap 封装，广泛用于高性能日志/队列
- MapDB：简单 KV 存储，底层大量使用 mmap
- LMAX Disruptor + mmap：极致低延迟场景组合
- Apache Arrow / Parquet mmap：大数据分析场景
一句话总结：
Java 中 mmap 技术主要通过 MappedByteBuffer 实现，是目前处理大文件随机读写、零拷贝、高性能持久化的最底层高效手段之一。
虽然使用门槛稍高、踩坑点多，但在性能敏感场景（日志系统、数据库、共享内存、KV 存储）仍然是不可替代的技术。
你现在想用 mmap 解决什么具体问题？
（大文件读取、日志追加、进程间共享数据、还是其他？）可以继续细聊～
