FileChannel.map适用于大文件（>10MB）且需随机读取或频繁重复访问的场景；小文件或单次顺序遍历反而更慢，只读用MapMode.READ_ONLY，读写需显式force()持久化，映射区域不可超文件当前长度，过大映射易触发Map failed异常。
FileChannel.map 适合什么文件大小和访问模式
映射只对**大文件（通常 >10MB）+ 随机读取或频繁重复访问**才真正提速。小文件用 map() 反而更慢，因为初始化映射页表、触发缺页中断的开销盖过了收益。顺序遍历一遍的小文件，FileInputStream + BufferedInputStream 往往更快。
只读场景优先选 MapMode.READ_ONLY；需要修改并同步到磁盘时用 MapMode.READ_WRITE，但注意：写入不立即落盘，必须显式调用 buffer.force() 才能保证持久化。
- 映射区域不能超过文件当前长度（否则抛
IOException: Map failed） - 映射过大（如 >2GB）可能触发
OutOfMemoryError: Map failed，这不是堆内存不足，而是进程虚拟地址空间或系统 mmap 限制所致 - 不支持动态扩容：如果映射后文件被其他进程增大，原
MappedByteBuffer不会自动延伸，再访问越界位置会抛IndexOutOfBoundsException
如何安全调用 map() 并避免资源泄漏
map() 本身不打开文件，它依赖底层的 FileChannel —— 而这个通道又绑定在 RandomAccessFile 或 FileInputStream 上。关错对象等于白关。
正确关闭顺序是：先关持有文件句柄的原始流/随机文件，再关 FileChannel（虽然关 channel 本身无害，但不关源头会导致句柄泄漏）。
- ❌ 错误写法：
channel.map(...)后只关channel.close()，没关raf.close()→ 文件锁残留、Windows 下无法删除文件 - ✅ 正确写法：用 try-with-resources 包裹
RandomAccessFile，让 JVM 自动确保raf和其getChannel()都被释放 - 映射后的
MappedByteBuffer不需要手动 close —— 它没有close()方法；它的生命周期由 GC 和底层 mmap 映射管理
读取时怎么避免 get() 调用变慢
MappedByteBuffer.get() 看似像数组访问，但每次调用都有边界检查开销。批量读取时，直接用 get(byte[] dst, int offset, int length) 或配合 asCharBuffer() / asIntBuffer() 等视图更高效。
尤其注意：MappedByteBuffer 默认是大端序（Big-Endian），如果文件是小端存储（如某些二进制协议），需先调用 buffer.order(ByteOrder.LITTLE_ENDIAN)，否则 getInt() 会读错。
- 不要在循环里反复调用
buffer.get(i)读单字节 —— 改用buffer.get(dstArray)批量拷贝 - 如果只是扫描文本内容，用
StandardCharsets.UTF_8.decode(buffer)比逐字节转 char 更可靠 -
buffer.isLoaded()返回 false 不代表数据不可读，只是说明操作系统尚未把全部页加载进物理内存；实际访问时会按需缺页加载，不影响正确性
为什么 map() 后读取还是卡？常见陷阱
映射本身不加载全部内容到物理内存，map() 只建立虚拟地址映射。首次访问某一页时触发缺页中断，由内核从磁盘加载 —— 这就是“懒加载”。如果你一上来就遍历整个 buffer，会引发大量同步 I/O，看起来像卡住。
想预热（prefetch），可调用 buffer.load()，它建议操作系统尽快把映射区域载入内存，但不阻塞，也不保证完成。真正想强制加载并等待，目前 Java 无标准 API，只能靠访问触发。
- Windows 上
load()基本无效，Linux 上效果也依赖内核版本和 vm.mmap_min_addr 设置 - 用
FileChannel.transferTo()复制文件时，别试图对目标 channel 调用map()再写 —— transferTo 已经是零拷贝，再 map 属于冗余操作且易出错 - 多线程并发读同一
MappedByteBuffer是安全的，但并发写READ_WRITE映射需自行加锁，JVM 不保证内存可见性
load() 或忘关 RandomAccessFile 的映射，可能比朴素的 BufferedReader 还难排查。 
