Direct Memory由操作系统分配且不受JVM堆GC直接管理，通过ByteBuffer.allocateDirect()调用Unsafe.allocateMemory()实现，受-XX:MaxDirectMemorySize限制；回收依赖Cleaner（虚引用+ReferenceQueue）在GC后异步触发Unsafe.freeMemory()。
Java里的Direct Memory（直接内存）不由JVM堆管理，而是通过java.nio.ByteBuffer.allocateDirect()在堆外分配，由操作系统负责物理内存映射。它的生命周期不直接受GC控制，但JVM通过Cleaner机制间接管理释放——本质上是利用虚引用+ReferenceQueue实现的延迟清理。
直接内存如何分配
调用ByteBuffer.allocateDirect(size)时，JVM底层通过Unsafe.allocateMemory()向操作系统申请内存（Linux下通常是mmap(MAP_ANONYMOUS)），跳过JVM堆。这部分内存不受-Xmx限制，但受系统资源和-XX:MaxDirectMemorySize约束（默认等于-Xmx）。超出限制会抛OutOfMemoryError: Direct buffer memory。
- 分配过程不触发GC，但会检查Direct内存使用量是否超限
- 每次分配都会更新全局计数器
Bits.reservedMemory，用于限流判断 - 底层返回的是一个long型地址（address），JVM用它构造DirectByteBuffer对象并维护其内存视图
Direct Memory如何回收
DirectByteBuffer对象本身在堆中，会被常规GC回收；真正释放堆外内存，依赖其内部关联的Cleaner。这个Cleaner继承自虚引用（PhantomReference），注册到ReferenceQueue中。当GC发现DirectByteBuffer不可达时，会把对应Cleaner加入队列，随后由Reference Handler线程调用其clean()方法，最终执行Unsafe.freeMemory(address)。
- 回收不是即时的：取决于GC时机、Reference Handler线程调度，可能有延迟
- 如果DirectByteBuffer长期被强引用（如缓存未及时clear），堆外内存无法释放，易导致OOM
- 可手动调用
buffer.cleaner().clean()强制触发（不推荐，存在竞态且非public API）
常见问题与规避建议
生产环境中Direct Memory泄漏往往表现为堆内存充足但频繁报Direct buffer OOM，或top显示进程RSS持续上涨。根本原因多为DirectByteBuffer未及时脱离作用域，或被意外持有（如Netty的PooledByteBuf未释放、线程局部缓存未清理）。
立即学习“Java免费学习笔记（深入）”；
- 避免长期持有DirectByteBuffer，尤其在线程池或静态容器中
- 使用Netty等框架时，严格遵循
release()规范；自定义NIO代码务必显式调用buffer.clear()或置null - 监控可用加JVM参数：
-XX:+PrintGCDetails -XX:+PrintReferenceGC，观察Cleaner处理情况 - 必要时设置合理上限：
-XX:MaxDirectMemorySize=2g，防止无节制占用
基本上就这些。Direct Memory不是“不用管”的内存，而是换了一种方式管理——靠GC间接驱动、靠Cleaner兜底释放。理解它，才能避开堆外内存的坑。
