System.gc() 对直接内存完全无效，它仅触发堆内对象回收，而直接内存由 Cleaner 异步释放，过程延迟且不可控；正确做法是主动管理引用并监控 native 内存指标。
System.gc() 对直接内存（Direct Memory）完全无效，它不参与、不触发、也不影响堆外内存的回收过程。
直接内存不由 System.gc() 管理
Java 中的直接内存（如 ByteBuffer.allocateDirect() 分配的内存）属于堆外内存（off-heap），由操作系统直接管理。JVM 的垃圾回收器只负责 Java 堆内对象的生命周期，System.gc() 仅作用于堆内对象，对 DirectByteBuffer 底层的 native 内存没有释放能力。
- DirectByteBuffer 本身是堆内对象，可被 GC 回收；但它的 native 内存释放依赖于其内部关联的
Cleaner（一种 PhantomReference 实现） - 只有当 DirectByteBuffer 对象被 GC 回收后，Cleaner 才可能被触发，进而异步调用
Unsafe.freeMemory()释放对应 native 内存 - 这个过程是延迟的、不可控的，且与 System.gc() 调用无直接因果关系
为什么有人误以为 System.gc() 能“帮助”释放直接内存
某些场景下（如 FileChannel.map() 或 allocateDirect() 抛出 OutOfMemoryError: Direct buffer memory），代码会紧接着调用 System.gc()，但这只是间接兜底策略：
- 目的是促使 JVM 尽快回收堆内的 DirectByteBuffer 实例，从而让 Cleaner 有机会运行
- 它不保证 Cleaner 立即执行，更不保证 native 内存立刻释放——中间还涉及 ReferenceHandler 线程调度、finalizer 队列处理等环节
- 在 JDK 9+ 中，Cleaner 已替代 finalize()，但仍无法绕过 GC 周期；而 System.gc() 在 G1/ZGC 下大概率被忽略，因此该策略成功率低、副作用大
真正可控的直接内存释放方式
依赖 System.gc() 是被动且不可靠的。更务实的做法是主动管理：
立即学习“Java免费学习笔记（深入）”；
- 显式调用
Buffer.clear()或Buffer.flip()不释放内存；必须确保 DirectByteBuffer 实例不再被任何强引用持有 - 使用
sun.misc.Unsafe（不推荐）或jdk.internal.ref.Cleaner（JDK 11+）手动注册清理逻辑（需反射或强依赖内部 API） - 改用
java.nio.channels.FileChannel.map()时，配合MappedByteBuffer.force()和close()（部分实现支持显式 unmap） - 通过 JVM 参数扩大直接内存上限：-XX:MaxDirectMemorySize=2g，避免因阈值过低频繁触发 OOM
验证直接内存是否释放的正确方法
不要看堆内存变化，而应观测 native 层指标：
- 启用 Native Memory Tracking：
-XX:NativeMemoryTracking=detail，再用jcmd <pid> VM.native_memory summary查看 direct arena 使用量 - 监控
java.lang.management.MemoryUsage中BufferPoolMXBean的totalCapacity和memoryUsed - 结合
PhantomReference<DirectByteBuffer>+ReferenceQueue，确认 ByteBuffer 对象已被 GC，这是 native 内存后续释放的前提信号
