堆外内存溢出本质是DirectByteBuffer持续占用本地内存且未释放，超出隐式上限（默认≈-Xmx），容器中易受cgroup限制；其不走GC、工具不可见，依赖脆弱的Cleaner机制，需-NMT或JFR监控。
堆外内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）的本质，是 JVM 管理的本地物理内存被 ByteBuffer.allocateDirect() 等方式持续占用，超出限制且未及时释放，最终耗尽所致。它不走 GC 流程，也不在堆内，因此常规堆分析工具完全“看不见”，容易误判为系统内存不足或 JVM 配置问题。
直接内存不受堆参数控制，但受隐式上限约束
默认情况下，JVM 并不显式设置直接内存上限，而是取 -Xmx 值作为默认上限（即 sun.misc.VM.maxDirectMemory() 返回值）。但这个“默认”非常脆弱：
- 在容器环境（如 Docker/K8s）中，cgroup 内存限额可能远低于 -Xmx，导致实际可用直接内存被系统级截断
- JDK 版本差异会影响默认行为（例如某些 JDK 17+ 在受限容器中自动适配 cgroup）
- 未配置
-XX:MaxDirectMemorySize时，看似“没设限”，实则依赖一个易被绕过或误读的默认值
分配源失控：高频、循环、未释放的 allocateDirect
真正触发溢出的，往往不是单次大分配，而是大量小而频繁、且未成对清理的调用：
- Netty 中启用了
PooledByteBufAllocator却漏掉buffer.release()，每次泄漏几 KB，积少成多 - NIO 文件通道（
FileChannel.transferTo/transferFrom）底层隐式使用 direct buffer，尤其在高吞吐小包场景下反复申请 - 自定义缓冲池未做容量控制或回收策略，或复用逻辑缺陷（如线程局部池未清理）
- 图像处理（OpenCV Java）、序列化（Kryo unsafe mode）、数据库驱动（pgjdbc 批量写入）等第三方库内部调用 allocateDirect，开发者无感知
释放机制失效：clean() 不执行，System.gc() 不可靠
DirectByteBuffer 的回收依赖 Cleaner 机制——它把释放逻辑注册为虚引用的“钩子”。但该机制存在明显短板：
立即学习“Java免费学习笔记（深入）”；
- 一旦 Cleaner 对象本身被提前回收（如强引用链断裂过早），或 JVM 忙于其他任务，clean() 就永远不会触发
- 依赖
System.gc()是危险做法：它不保证立即执行，且在 G1/ZGC 等现代 GC 下基本被忽略；频繁调用反而拖慢性能 - 没有显式 close() 或 release() 接口的类（如部分 NIO Channel 包装器），容易让 buffer “悬空”在 native 层
监控盲区：常规 GC 工具无法反映真实占用
jstat、jmap、VisualVM 等工具主要观测堆和元空间，对直接内存“视而不见”：
-
jstat -gc显示 MU/CCSC 正常，但 OOM 报的是 Direct buffer memory → 可直接排除堆和元空间问题 - 必须启用
-XX:NativeMemoryTracking=summary，再用jcmd <pid> VM.native_memory summary查看 “direct” 分项趋势 - JFR（Java Flight Recorder）开启
jdk.NativeMemoryUsage事件，才能精准定位每次 allocateDirect 的调用栈和大小
