内存映射文件不提供堆外变量空间，真正存储超大规模集合的是JVM堆外内存；它绕过GC、减少对象头与指针开销、支持紧凑布局，适用于亿级小对象集合；可通过Unsafe手动分配、Chronicle Map等库或Spark堆外配置实现。
内存映射文件（Memory-Mapped Files）本身不直接提供“堆外变量空间”来存集合，它本质是将磁盘文件按页映射到进程的虚拟地址空间，由操作系统管理物理内存与磁盘的换入换出。真正用于存储超大规模集合的堆外空间，来自 JVM 的 堆外内存（Off-heap Memory），而非 mmap 映射区——但二者可协同使用：mmap 负责高效 I/O 调度，堆外内存负责低延迟、大容量、GC 无关的数据结构承载。
为什么不用堆内，而选堆外存集合？
Java 堆内存放集合（如 HashMap、ArrayList）受限于 GC 压力、对象头开销（12–16 字节/对象）、引用指针（4 或 8 字节）、以及 Full GC 时的 Stop-The-World 风险。当集合元素达亿级、单个对象实例小（如 int、long、short 结构），堆内存极易碎片化、OOM 频发。堆外内存绕过 JVM GC，直接由 Unsafe 或 DirectByteBuffer 管理，支持紧凑二进制布局，内存利用率高、访问延迟稳定。
如何用堆外内存构建可扩展集合？
关键不是“把 ArrayList 放堆外”，而是采用面向堆外设计的数据结构：
-
基于 Unsafe 手动分配 + 偏移寻址：用
Unsafe.allocateMemory(size)申请连续裸内存，按固定字节宽度（如 8 字节 long）划分槽位，用putLong(address + offset, value)写入，实现类似 LongArray 的零拷贝数组； - 使用成熟堆外集合库：如 Chronicle Map（支持持久化、并发读写、自动分段）、Agrona’s MutableDirectBuffer + Hashing（轻量级、无 GC 依赖）、或 RoaringBitmap（堆外布尔向量压缩）；
-
配合内存映射做冷热分离：热数据（高频访问键值）驻留堆外内存；冷数据（低频或历史分区）映射为只读 mmap 文件，通过
MappedByteBuffer.load()按需加载页，避免全量载入。
Spark 场景下的典型实践
Spark 本身已内置堆外集合支持路径：
- 启用
spark.memory.offheap.enabled=true并设spark.memory.offheap.size=10g，其统一内存管理会将 storage 和 execution 内存划入堆外，缓存 RDD 时自动使用堆外 BufferPool； - 广播变量（Broadcast）若为大型查找表（如用户画像 ID→标签映射），可序列化后存入堆外内存，避免 driver → executor 的重复传输与堆内复制；
- Shuffle 输出阶段，
Tungsten引擎默认使用堆外内存管理排序缓冲区和 hash 表，显著降低 GC 开销，支撑百亿级 shuffle record 处理。
注意事项与边界
堆外内存不受 JVM 自动回收约束，必须显式释放（Unsafe.freeMemory() 或 DirectByteBuffer.cleaner().clean()），否则造成内存泄漏；监控需依赖 sun.misc.VM.maxDirectMemory() 与 NIO BufferPool 指标；Linux 系统还需关注 /proc/sys/vm/max_map_count，避免 mmap 区域耗尽导致映射失败。
