堆外内存溢出（Direct buffer memory）需确认泄漏类型→定位allocateDirect调用源→阻断未释放行为；通过NMT监控、jcmd分析Direct区、检查Netty/NIO缓冲区释放，显式设-XX:MaxDirectMemorySize并池化复用。
看现象，先区分是“Direct Memory”还是“Native Memory”泄漏
不是所有堆外增长都叫 DirectBuffer 溢出：
- Direct buffer memory：报错明确带这串文字，说明 `ByteBuffer.allocateDirect()` 分配的堆外内存没释放，或 `MaxDirectMemorySize` 设置过小（默认≈`-Xmx`）；
- Native memory leak（如 JNI、NIO Channel、压缩/加密库等）：无明确 OOM 报错，但 `top` 中 RES 持续上涨（比如 `-Xmx=2g`，RES 却涨到 5g+），且 `jstat`、`jmap` 显示堆内正常；
-
Metaspace / Thread / CodeCache 异常增长：虽属“非堆”，但属于 JVM 自管理区域，可通过 `jstat -gcmetacapacity` 或 `jcmd
VM.native_memory summary` 快速排除。
用工具抓证据，别靠猜
启动时务必加参数，出问题才有依据：
- 启用原生内存追踪：
-XX:NativeMemoryTracking=detail（有约5%性能开销，建议预发/线上低峰开启）； - 监控 DirectBuffer 使用：
-XX:+PrintGCDetails -Xlog:gc+metaspace+native_memory=debug（JDK11+）； - 运行中检查：
jcmd <pid> VM.native_memory summary scale=MB</pid>，重点关注Internal、Other、Thread和Direct三栏变化； - 查 DirectBuffer 分配点：
jstack <pid> | grep -A5 -B5 "allocateDirect"</pid>，结合业务代码定位调用方。
常见泄漏点和修复方式
堆外泄漏往往藏在“看起来很安全”的封装里：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- NIO 文件读写未关闭：`Files.readAllBytes(path)` 返回 byte[] 不涉及 DirectBuffer，但 `FileChannel.map()` 或 `AsynchronousFileChannel` 的 `read(ByteBuffer, ...)` 若传入 `allocateDirect` 缓冲区且未复用/清理，会累积；
- Netty / Dubbo 等框架缓冲区未释放：`ByteBuf.release()` 忘调、`PooledByteBufAllocator` 配置不当、或 `ReferenceCounted` 对象被 static 引用持有；
- 自定义 JNI 库未 free 内存：C/C++ 层 malloc 后未对应 free，或 Java 层未触发 `Cleaner` 回调；
- ZipInputStream / Cipher / ImageIO 等 JDK 类内部使用 DirectBuffer：尤其在流式处理大文件时，未及时 close 导致底层 DirectBuffer 无法回收。
修复原则：显式释放、池化复用、避免静态持有。例如 Netty 场景下，确保每个 `ByteBuf` 在 handler 处理完后调用 buf.release()；NIO 场景下优先用 `ByteBuffer.wrap(byte[])` 替代 `allocateDirect`，或严格配合 try-with-resources。
兜底配置与验证
参数只是辅助，不能替代代码修复：
- 设上限防失控：
-XX:MaxDirectMemorySize=512m（根据业务峰值合理设置，勿盲目调大）； - 避免堆外与堆争内存：
-Xmx2g -XX:MaxDirectMemorySize=512m，总和不超过容器/物理内存； - 上线后验证：用 `jcmd
VM.native_memory detail.diff` 对比两次快照，确认 `Direct` 区不再持续增长； - 长期运行观察：重点盯 `top -p
-b -n 2 | grep 'RES'`，确认 RES 趋于平稳而非单边爬升。
