mappedbytebuffer读超大文件反而更慢或崩溃，因其不管理native内存、依赖不可控gc清理、受max_map_count限制、>2gb需分段映射且易触发os级oom；仅适用于随机读、只读、热数据局部性好的场景。
MappedByteBuffer 不是万能的“超大文件加速器”，它在特定场景下有效，但滥用会导致 OOM、GC 压力飙升甚至进程被系统 kill。
为什么 MappedByteBuffer 读超大文件反而更慢或崩溃
很多人以为内存映射 = 零拷贝 + 快速访问，实际不是。JVM 不管理 MappedByteBuffer 占用的 native 内存，DirectByteBuffer 的清理依赖 GC 触发 Cleaner，而这个过程不可控、延迟高。Linux 下还受限于 /proc/sys/vm/max_map_count（默认通常 65530），单个 JVM 映射太多区域会直接抛 IOException: Cannot allocate memory。
- 文件 >2GB 时，
FileChannel.map()返回的MappedByteBuffer是ByteBuffer，不支持long偏移，必须分段映射 - 映射后未显式调用
force()，修改不会落盘；但频繁force()会退化成同步写 - 映射整个 100GB 文件？OS 页表会爆，JVM 进程可能被 OOM Killer 杀掉，而不是抛 Java 异常
如何安全地分段映射并读取 >2GB 文件
核心是控制每次映射长度 ≤2GB（即 Integer.MAX_VALUE），并手动管理 offset 和 remaining。不要试图“一次映射全部”。
- 计算每段大小：
long segmentSize = Math.min(2L * 1024 * 1024 * 1024, fileSize - offset) - 用
channel.map(MapMode.READ_ONLY, offset, segmentSize)获取当前段；注意offset和segmentSize都是long，但后者不能超过Integer.MAX_VALUE（否则抛IllegalArgumentException） - 读完一段后，显式调用
buffer.clear()或丢弃引用，但无法强制立即释放 native 内存——这是最常被忽略的风险点 - 若需确定释放（如长期运行服务），可反射调用
sun.misc.Cleaner（不推荐）或改用Files.readAllBytes(path)+ 流式处理替代
// 示例：读取第 5GB 开始的 1MB long offset = 5L * 1024 * 1024 * 1024; int size = 1024 * 1024; MappedByteBuffer buf = channel.map(MapMode.READ_ONLY, offset, size); byte[] data = new byte[size]; buf.get(data); // 注意：buf.position() 会移动
MappedByteBuffer vs FileChannel.transferTo() 的真实适用场景
内存映射不是读写提速的银弹。它的优势只在「随机访问密集 + 热数据局部性好」的场景，比如数据库索引文件、日志检索。顺序扫描大文件？transferTo()（配合 SocketChannel）或带 buffer 的 InputStream 更稳。
-
MappedByteBuffer适合：按 key 查找固定偏移记录（如 LevelDB SSTable）、内存中快速二分搜索 -
transferTo()适合：文件拷贝、HTTP 大文件响应（零拷贝到 socket）、无需解析内容的透传 - 写入大量小块？
MappedByteBuffer的 page fault 开销可能高于FileChannel.write()+ByteBufferpool - Windows 下
MappedByteBuffer对删除/截断中的文件行为未定义，Linux 下也可能出现 SIGBUS
必须检查的三个系统与 JVM 配置
没调这些，MappedByteBuffer 很容易在线上出 silent failure。
- Linux：
cat /proc/sys/vm/max_map_count—— 建议设为655360（10× 默认），否则并发映射多个大文件必挂 - JVM：
-XX:MaxDirectMemorySize要覆盖所有映射总和（虽然它不真正限制 native 映射，但影响DirectByteBufferCleaner 触发阈值） - 文件系统：避免在 NFS 或某些 FUSE 文件系统上使用 ——
mmap()语义不保证，可能返回 stale 数据或Invalid argument
真正棘手的是：native 内存泄漏不会触发 Java OOM，只会让 top 看到 RSS 持续上涨，直到被系统回收。上线前务必用 pmap -x <pid></pid> 和 cat /proc/<pid>/maps | grep '^7' | wc -l</pid> 监控映射区数量。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
