Java外部内存并非绕过JVM，而是由JVM可控扩展的堆外内存（Off-heap），通过ByteBuffer.allocateDirect等API申请，依赖Cleaner或显式clean()释放，受-XX:MaxDirectMemorySize约束，用于减压与提效，不可滥用或脱离JVM管理。
Java外部内存技术不能“绕过”JVM堆内存管理来规避JVM的设计约束，也不能用于规避GC或安全机制——这是常见误解。正确目标应是：在JVM可控、安全的前提下，减少堆内存压力、提升大块数据的I/O与序列化效率。核心手段是使用堆外内存（Off-heap Memory），但必须由JVM统一参与管理（如通过Unsafe或ByteBuffer.allocateDirect），而非脱离JVM。
理解堆外内存的本质与边界
堆外内存由操作系统直接分配，不受GC自动回收，但仍受JVM生命周期约束（如DirectByteBuffer对象本身在堆上，其清理依赖Cleaner或显式clean()）。它不等于“绕开JVM”，而是JVM提供的受控扩展能力。
- 所有堆外内存申请最终调用的是操作系统的mmap或malloc，但JVM会记录用量（可通过-XX:MaxDirectMemorySize控制上限）
- 未及时释放的DirectByteBuffer会导致堆外内存泄漏，表现为java.lang.OutOfMemoryError: Direct buffer memory，而非堆OOM
- Unsafe.allocateMemory已自JDK 9起被限制，默认不可用；需添加--add-opens java.base/jdk.internal.misc=ALL-UNNAMED且不推荐生产使用
推荐方式：用DirectByteBuffer处理海量数据
这是标准、安全、可监控的堆外方案，适用于文件映射、网络缓冲、序列化中间层等场景。
- 创建：ByteBuffer buf = ByteBuffer.allocateDirect(1024 * 1024 * 100); // 分配100MB堆外空间
- 写入：buf.putInt(123).putLong(456L).flip();
- 读取：int x = buf.getInt(); long y = buf.getLong();
- 释放：buf.clear(); // 不释放内存；真正释放依赖GC回收DirectByteBuffer对象 + Cleaner执行freeMemory()
- 主动释放（JDK 14+）：((Buffer) buf).cleaner().clean(); 或反射调用sun.misc.Cleaner（不建议长期依赖）
配合MappedByteBuffer实现零拷贝文件处理
适合超大只读/追加日志、索引文件等场景，避免传统IO的内核态-用户态拷贝。
立即学习“Java免费学习笔记（深入）”；
- FileChannel.map(FileChannel.MapMode.READ_ONLY, offset, size) 返回MappedByteBuffer，本质是堆外内存映射
- 注意：映射区域过大可能引发系统级OOM（如Linux的vm.max_map_count限制）
- 取消映射无标准API；通常靠GC回收MappedByteBuffer触发unmap；若需立即释放，可用Unsafe或jdk.internal.ref.Cleaner（需强耦合JDK内部类）
- 务必配合try-with-resources或显式force()确保脏页落盘（WRITE_ONLY / READ_WRITE模式下）
生产环境关键注意事项
堆外内存不是银弹，滥用反而增加运维复杂度和稳定性风险。
- 监控：通过-XX:+PrintGCDetails观察DirectMemory增长；用jcmd <pid> VM.native_memory summary查看实时堆外用量
- 配置：务必设置-XX:MaxDirectMemorySize（如4g），否则默认等于-Xmx，易导致意外OOM
- 替代思路优先考虑：分片处理、流式解析（如Jackson Streaming API）、内存映射+索引结构、或迁移到更适合大数据的运行时（如GraalVM Native Image对堆外更友好）
- 禁止在应用中自行调用System.loadLibrary加载native库管理内存——这完全脱离JVM管控，违反Java安全模型
