直接内存是JVM通过Unsafe.allocateMemory向OS申请的堆外内存，由OS管理、地址稳定、支持零拷贝，但不受GC控制；分配时创建轻量DirectByteBuffer对象并校验-XX:MaxDirectMemorySize，回收依赖Cleaner异步触发，易因引用滞留导致泄漏。
直接内存（Direct Memory）不是 JVM 堆的一部分，而是 JVM 通过本地方法（如 Unsafe.allocateMemory）向操作系统直接申请的一块本地内存。它由 OS 管理，地址稳定、支持 DMA 和零拷贝，但不受 GC 控制——理解这一点，是掌握其分配与回收逻辑的关键。
分配：不走堆，只靠 Unsafe + 限额检查
调用 ByteBuffer.allocateDirect(n) 时，JVM 并不会在堆里分配 n 字节数据，而是在堆内创建一个轻量级的 DirectByteBuffer 对象（约 24 字节），同时调用 Unsafe.allocateMemory(n) 向 OS 申请 n 字节物理连续内存。
这个过程会触发限额校验：
– 检查是否超过 -XX:MaxDirectMemorySize（默认等于 -Xmx）
– 若超限，立即抛出 OutOfMemoryError: Direct buffer memory，不等 GC 发生
- 分配是同步、即时的，不依赖 GC 周期
- 每次调用都可能触发系统调用（如 mmap 或 malloc），开销比堆分配高
- 即使堆内存充足，
-XX:MaxDirectMemorySize设得太小也会导致分配失败
回收：不自动，靠 Cleaner 被动触发
DirectByteBuffer 对象本身在堆中，会被 GC 正常回收；但它持有的堆外内存不会随对象消失而释放。真正释放动作，由关联的 Cleaner（JDK9+ 是 jdk.internal.ref.Cleaner，JDK8 是 sun.misc.Cleaner）异步执行。
这个机制依赖虚引用（PhantomReference）和一个后台守护线程（CleanerThread），流程是：
立即学习“Java免费学习笔记（深入）”；
- GC 发现
DirectByteBuffer不可达 → 将其 Cleaner 入队到 ReferenceQueue - CleanerThread 监听到后，调用
Deallocator.free()释放对应堆外内存 - 整个过程延迟不可控：若老年代长期不 GC，Cleaner 就一直卡着不执行
⚠️ 注意：不能手动调 cleaner.clean()，也不该靠 System.gc() 强制催 —— 这既低效又干扰正常 GC 节奏。
泄漏风险：不是没释放，而是“释放不了”
常见泄漏场景不是代码完全忘了释放，而是让 DirectByteBuffer 无法被 GC：
- 缓存中长期持有 DirectBuffer 引用（比如用
ConcurrentHashMap存着没清理） - Netty 中用了
PooledByteBufAllocator却未调.release()，导致池子满后不断 new 新 buffer - Channel 未 close，底层关联的 DirectBuffer 一直被 NIO selector 持有
此时堆内 DirectByteBuffer 实例数持续增长（可用 jmap -histo:live 查），堆外内存却迟迟不归还，RSS 持续上涨，最终 OOM 或被系统 kill。
怎么才算“安全释放”？
真正的可控释放，靠的是显式管理 + 池化 + 作用域约束：
- 使用 Netty、AIO 等框架时，严格遵循
release()/close()生命周期契约 - 避免无池化高频 allocateDirect；优先用
PooledByteBufAllocator复用内存 - 在 try-finally 或 try-with-resources（需封装适配）中确保 release，不依赖 Cleaner 的“事后补救”
- 配合
-XX:NativeMemoryTracking=detail+jcmd <pid> VM.native_memory summary</pid>定期核对 direct 区用量
