Direct Memory是操作系统分配的堆外内存，通过ByteBuffer.allocateDirect()申请，由Cleaner机制异步释放；需主动调用clean()或使用AutoCloseable/ReferenceCounted避免OOM。
Direct Memory（直接内存）不是JVM堆内存的一部分，而是由操作系统直接分配的本地内存，常用于NIO、高性能网络通信（如Netty）、大文件读写等场景。它绕过JVM堆，减少GC压力，但需手动管理生命周期——申请不及时释放会导致内存泄漏，甚至触发OOM（OutOfMemoryError: Direct buffer memory）。
如何申请Direct Memory
最常用方式是通过ByteBuffer.allocateDirect()：
- 调用后，JVM向操作系统申请一块本地内存，并返回一个DirectByteBuffer对象；
- 该对象本身很小（在堆中），仅持有一个地址指针和清理器（Cleaner），真正数据存在堆外；
- 默认大小受-XX:MaxDirectMemorySize限制（未设置时通常等于-Xmx值）；
- 也可用Unsafe.allocateMemory()（需反射获取Unsafe实例），但属内部API，不推荐生产使用。
何时触发释放
Direct Memory的释放依赖Java对象的垃圾回收与Cleaner机制协同工作：
- 当DirectByteBuffer对象被GC判定为不可达，其关联的Cleaner会被加入待执行队列；
- Cleaner后台线程（FinalizerThread或Reference Handler线程）调用Deallocator.run()，最终调用Unsafe.freeMemory()归还内存；
- 这个过程是非即时的，可能延迟数秒甚至更久，尤其在GC不频繁或堆内存充足时；
- 若大量DirectByteBuffer短期创建又丢弃，而GC滞后，极易突破MaxDirectMemorySize阈值。
主动释放的最佳实践
对关键路径或长生命周期的DirectBuffer，应避免依赖GC自动清理：
- 使用((DirectBuffer) buffer).cleaner().clean()强制触发释放（注意：仅对DirectBuffer有效，且clean()是幂等的）；
- 配合try-with-resources，自定义实现AutoCloseable包装类，在close()中调用clean()；
- Netty等框架已封装ReferenceCounted机制，调用release()即可递减引用并自动释放；
- 监控建议：通过java.lang.management.ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage()或JDK自带jstat（jstat -gc <pid>）观察Direct内存使用趋势。
常见问题与规避
典型陷阱包括：
- 忘记释放+GC滞后 → 设置合理-XX:MaxDirectMemorySize，并在压测中观察Direct内存增长曲线；
- 重复clean() → 不会报错，但无意义；clean()内部有状态标记，多次调用只释放一次；
- buffer已释放却继续访问 → 触发Segmentation Fault（Linux）或Access Violation（Windows），JVM通常直接崩溃；
- Native层长期持有指针（如JNI中缓存了address）→ Java层释放后指针变野指针，必须同步管理生命周期。
