Java直接内存管理与回收机制解析

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未释放、线程局部缓存未清理）。

• 避免长期持有DirectByteBuffer，尤其在线程池或静态容器中
• 使用Netty等框架时，严格遵循release()规范；自定义NIO代码务必显式调用buffer.clear()或置null
• 监控可用加JVM参数：-XX:+PrintGCDetails -XX:+PrintReferenceGC，观察Cleaner处理情况
• 必要时设置合理上限：-XX:MaxDirectMemorySize=2g，防止无节制占用

基本上就这些。Direct Memory不是“不用管”的内存，而是换了一种方式管理——靠GC间接驱动、靠Cleaner兜底释放。理解它，才能避开堆外内存的坑。