FileChannel.map() 映射大文件不立即加载数据，访问时才触发缺页中断加载，全量映射或遍历 MappedByteBuffer 会导致卡顿；进程间通信需手动同步、统一命名和原始数据布局。
直接说结论：Java 的 FileChannel.map() 能让大文件读取“看起来”秒级，但前提是别全量映射、别乱用 MappedByteBuffer.get() 扫描整块、别忽略缺页延迟；进程间通信不是靠 mmap 本身，而是靠你手动加同步 + 统一命名 + 原始数据布局。
为什么 FileChannel.map() 映射 2GB 文件后一访问就卡住
这不是 Java 慢，是操作系统在“按需加载”——map() 只建虚拟地址映射，真正读到某页时才触发缺页中断、从磁盘加载。如果你用 for (int i = 0; i 猛扫，等于强制把全部 2GB 页面拉进物理内存，IO 就炸了。
- 避免全量映射：用
channel.map(mode, offset, size)分段映射，比如每次只映射 64MB，读完再 map 下一段 - 别用
get(i)遍历：改用buffer.get(byteArray)批量读，或直接unsafe.copyMemory（需Unsafe权限） - 只在真正需要随机访问时用 mmap：顺序读大文件，
FileChannel.read(ByteBuffer)+ 合理 buffer size（如 1MB）往往更快、更稳
两个 Java 进程怎么用同一个 mmap 区域安全通信
MemoryMappedFile 是 .NET 的类名，Java 里没这东西；Java 进程间共享 mmap，本质是“多个进程调用 map() 映射同一个文件的同一区域”，但光映射没用，不加同步就是裸奔。
- 文件必须是真实磁盘文件（不能是临时文件或 /dev/shm），且所有进程用相同路径打开
- 映射模式得一致：
MapMode.READ_WRITE或MapMode.PRIVATE，READ_ONLY无法写入，通信失效 - 命名不解决任何问题：Java 没
Global\命名空间概念，靠文件路径唯一标识；Windows 上注意路径权限，Linux 上注意 umask 和文件属主 - 必须配同步原语：比如用
FileLock（推荐）或外部ReentrantLock+AtomicInteger控制读写序，否则写一半就被读，数据撕裂
MappedByteBuffer 读写报 IllegalArgumentException 或 BufferUnderflowException
这不是文件损坏，是缓冲区状态错了。常见于反复 map() 后没释放旧 buffer，或 position/limit 混乱导致越界。
- 映射后立即调用
buffer.order(ByteOrder.nativeOrder())，尤其涉及多进程结构体解析时，大小端必须统一 - 不要长期持有
MappedByteBuffer实例：它不自动释放底层 mmap，JVM GC 不管它；频繁映射要手动cleaner（非公开 API）或复用固定 buffer - 写结构体时，别用
putInt()直接写偏移：先buffer.position(offset).putInt(value)，否则 position 漂移会导致后续读错位 - 跨进程读结构体，必须用
@StructLayout(LayoutKind.Sequential)类似逻辑：Java 侧用ByteBuffer+getInt(0),getLong(4)等绝对偏移访问，禁用asIntBuffer()等视图封装
大文件处理中 mmap 和普通 FileChannel 的性能分水岭在哪
没有银弹。mmap 的优势只在特定组合下成立：随机访问频次高 + 单次访问跨度大 + 文件热数据集中在局部区域。其他情况反而拖慢。
- 顺序读 10GB 日志？用
FileChannel.read()+ 2MBByteBuffer，比 mmap 快 15–20%，因为少了页表管理开销 - 数据库索引查找？mmap 合适：B+ 树节点分散，随机跳转多，mmap 天然支持 O(1) 定位
- 进程间共享 500MB 配置块？mmap +
FileLock是最优解：零拷贝、无序列化、内核级同步 - 注意 JVM 堆外内存监控：
MappedByteBuffer占用的是 native memory，jstat -gc看不到，得用NMT（Native Memory Tracking）开启跟踪
最易被忽略的一点：mmap 的“高效”依赖操作系统页缓存命中率。如果文件刚写入就立刻 mmap 读，且系统内存紧张，缺页中断会大量回刷 dirty page，此时比传统 I/O 还慢。上线前务必用真实负载压测缺页率（perf stat -e page-faults）。
