堆外内存回收依赖DirectByteBuffer对象被GC回收后触发Cleaner清理，不参与JVM堆内GC流程；Full GC仅在Direct Buffer OOM且MaxDirectMemorySize受限时被动触发，G1/ZGC等新收集器亦无特殊优化。
堆外内存（Direct Memory）的回收本身不参与JVM堆内GC流程，但它会在特定条件下触发或依赖传统垃圾收集器的联动行为。这种联动不是主动协作，而是被动响应——核心在于DirectByteBuffer对象的生命周期结束时机。
DirectByteBuffer对象是堆外内存回收的“开关”
每个DirectByteBuffer实例在堆内只占几十字节（对象头+address、capacity等字段），真正数据存于堆外。JVM无法直接感知堆外内存是否该释放，只能等这个“壳子”被GC判定为不可达并回收时，才顺带清理它背后的堆外空间。
- 只要DirectByteBuffer对象仍被强引用（比如放在静态Map里、未close、未置null），哪怕堆外已闲置，内存就一直占用
- 一旦GC将该对象回收，其内部关联的Cleaner会被唤醒，调用Unsafe.freeMemory释放对应堆外地址
- 这个过程发生在GC完成后的Reference Handler线程中，不是GC线程本身执行，但强依赖GC的标记与回收动作
Full GC可能被显式用来“逼出”堆外内存回收
当Direct Buffer分配失败抛出java.lang.OutOfMemoryError: Direct buffer memory时，JVM会尝试触发一次Full GC——目的是尽快回收那些已失去引用的DirectByteBuffer对象，从而释放它们持有的堆外内存。
- 这属于“兜底机制”，并非每次DirectBuffer分配都会触发，仅在-XX:MaxDirectMemorySize设限且已达上限时发生
- 若堆内存在大量未被回收的DirectByteBuffer（比如因弱引用/软引用未及时清理、或对象长期存活在老年代），Full GC未必能立刻释放足够堆外空间
- 该行为受-XX:+DisableExplicitGC影响：若禁用System.gc()，此自动触发也可能被抑制（取决于JVM版本和GC策略）
元空间与堆外内存无直接联动，但间接影响GC频率
元空间（Metaspace）不足引发的Full GC，本身不释放堆外内存；但它会增加GC压力，可能延缓DirectByteBuffer对象进入回收队列的时间。
- 频繁元空间GC → 应用暂停增多 → 弱引用队列处理延迟 → Cleaner注册滞后 → 堆外内存释放变慢
- 尤其在类加载密集场景（如热部署、OSGi），元空间膨胀可能挤占GC资源，间接拖累堆外内存回收效率
G1与ZGC等新收集器对堆外回收无特殊优化
目前主流GC算法（包括G1、ZGC、Shenandoah）均未将堆外内存纳入其并发标记或回收阶段。它们仍遵循同一逻辑：只管堆内对象可达性，Cleaner机制保持不变。
- G1的Mixed GC不会扫描DirectByteBuffer的堆外引用关系
- ZGC的并发标记只遍历Java堆，不检查本地内存映射
- 所有堆外释放仍由Reference Handler线程串行执行，存在潜在瓶颈
