NMT是定位JVM堆外内存泄漏的核心工具，需启动时配置-XX:NativeMemoryTracking=detail和-XX:+UnlockDiagnosticVMOptions，通过jcmd对比baseline与diff快照，重点监控Internal、Thread、Metaspace、Other四大区域，并辅以pmap、smaps等系统命令交叉验证。
堆外内存泄漏排查不能只盯着堆 dump，NMT 是唯一能直接告诉你“JVM 自己到底用了多少原生内存”的官方工具。它不依赖 GC，也不看对象引用链，而是从操作系统层面统计 JVM 各模块的内存申请行为——这才是定位非 Java 堆内存异常增长的核心突破口。
启用 NMT 的关键参数组合
NMT 必须在 JVM 启动时开启，且需配合诊断选项解锁：
- -XX:NativeMemoryTracking=detail：生产排查首选，能追踪到 DirectByteBuffer 分配栈、Unsafe 调用点、JNI 模块等具体来源；summary 模式仅显示大类汇总，无法定位代码行
- -XX:+UnlockDiagnosticVMOptions：必需项，否则 jcmd 调用 VM.native_memory 会报错“not supported”
- 可选加 -XX:+PrintNMTStatistics：启动时自动打印初始内存分布，方便快速确认是否生效
用 jcmd 抓取并对比内存快照
单次快照意义有限，关键在于“变化量”。推荐三步操作：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 应用刚启动、业务未触发时执行：jcmd
VM.native_memory baseline ，建立基线 - 运行一段时间（如 10–30 分钟）或复现疑似泄漏场景后，执行：jcmd
VM.native_memory summary.diff scale=MB - 重点关注 diff 输出中增长显著的模块：Internal（含 DirectBuffer）、Thread（线程数暴增）、Other（Unsafe/JNI）、Metaspace（动态类加载）
重点盯防的四大高危区域
NMT 输出中以下四类是堆外泄漏最常发生的“重灾区”，需结合业务逻辑交叉验证：
立即学习“Java免费学习笔记（深入）”；
- Direct Memory：查看 Internal 下的 “direct memory” 字段。若持续增长且与 ByteBuffer.allocateDirect() 调用量匹配，检查是否漏调 cleaner().clean() 或未关闭 Netty/Grpc 的 ByteBuf
- Thread：对比 Thread 的 reserved/committed 值与实际线程数（jstack | grep java.lang.Thread | wc -l）。若 committed 接近 reserved，说明线程栈未释放，常见于线程池未 shutdown 或异步任务未 await
- Metaspace：观察 Class 区域 committed 是否缓慢爬升。Spring Boot 热部署、OSGi、或频繁 defineClass 的场景易触发，需检查类加载器是否泄漏
- Other：detail 模式下该区域会显示 Unsafe.allocateMemory 或 JNI 调用栈。若增长明显，需审查本地库使用（如图像处理、加密 SDK）或自定义 Unsafe 内存操作
辅助验证：用系统命令交叉印证
NMT 只跟踪 JVM 主动申请的内存，第三方 native 库（如 OpenSSL、FFmpeg）不在其监控范围。当 NMT 显示稳定但 RSS 仍在涨，需补充检查：
-
pmap -x
| sort -k3 -n | tail -20 ：找大块匿名内存（anon），64MB/128MB 等固定大小块往往是 DirectBuffer 或 mmap 分配 -
cat /proc/
/smaps | awk '/^Size:/ {sum+=$2} END {print sum}' ：获取进程总虚拟内存，与 NMT 的 Total reserved 对比，偏差过大说明有 JVM 外内存分配 -
jstat -gc
与 top -p 并行观察：若堆 GC 正常但 RES 持续上扬，基本可锁定堆外问题
