直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）是堆外物理内存耗尽所致，不走GC流程，需通过-XX:MaxDirectMemorySize限制、追踪allocateDirect调用、强制clean或改用堆内缓冲解决。
直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）不是堆内存问题，而是 JVM 管理的堆外物理内存耗尽所致。它不走 GC 流程，常规堆分析工具抓不到，容易误判成系统资源不足。排查核心就四件事：确认真用了直接内存、查清谁在疯狂分配、看实际用了多少、验证释放是否到位。
确认是否触发了 Direct Memory 限制
默认情况下，JVM 最大直接内存 ≈ -Xmx 值，但真正起作用的是 -XX:MaxDirectMemorySize 参数。没显式设置时，HotSpot 通常取 Runtime.getRuntime().maxMemory()，但在容器环境里可能被 cgroup 限制压得更低，导致实际可用远小于预期。
- 启动时加参数打印当前限制：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中是否频繁出现 DirectBuffer 分配失败提示 - 代码里主动输出：
System.out.println("MaxDirectMemory: " + sun.misc.VM.maxDirectMemory() / 1024 / 1024 + " MB"); - 用
jstat -gc <pid>查 CCSC 和 MU 没异常，但 OOM 报的是 Direct buffer，基本能锁定是这块出了问题
定位非法或失控的直接内存分配源
常见高危场景集中在 NIO 相关操作：Jetty/Netty/Undertow 等网络框架、自定义 ByteBuffer 缓冲池、OpenCV Java binding 图像处理、Kryo（unsafe mode）序列化等。
- 全局搜索项目中所有
ByteBuffer.allocateDirect()调用点，特别关注循环、递归、连接复用但未清理的逻辑 - 检查 Netty 是否启用了
PooledByteBufAllocator却漏掉buffer.release()—— 每次release()必须和alloc()成对出现，漏一次就泄漏一块 - 启用 Native Memory Tracking：
-XX:NativeMemoryTracking=summary，再用jcmd <pid> VM.native_memory summary查 direct 内存实际占用趋势 - 开启 JFR（Java Flight Recorder），启用
jdk.NativeMemoryUsage事件，可精准捕获每次allocateDirect的调用栈
强制限制 + 主动回收双保险
不能只靠“调大内存”，必须设硬上限，并确保释放路径可靠。
立即学习“Java免费学习笔记（深入）”；
- 启动参数明确限制：例如
-XX:MaxDirectMemorySize=512m（推荐设为堆内存的 1/4～1/2，避免挤占系统内存） - Netty 场景下可临时规避：
-Dio.netty.noPreferDirect=true强制改用堆内缓冲 - 对已分配但未释放的 DirectBuffer，可尝试反射调用
Cleaner强制清理（仅限紧急诊断，不建议生产长期依赖）
避免踩坑的实操细节
有些看似合理操作反而会加剧问题：
- 单纯加大
-Xmx对 Direct buffer OOM 无效，甚至可能让问题更隐蔽（因为默认 MaxDirectMemorySize 会跟着变大） - 别依赖
System.gc()触发 Cleaner 清理 —— 它不保证执行，且影响性能 - 使用
Unsafe或 JNI 直接操作内存的第三方库，也要纳入排查范围，它们同样绕过 JVM 堆管理
