NMT能定位JVM自身分配的堆外内存增长点，但无法监控第三方native库（如OpenSSL、Netty底层C代码）的内存；它可揪出90%的DirectByteBuffer、Unsafe、JIT和GC内部泄漏。
直接结论：NMT 能定位 JVM 自身分配的堆外内存增长点，但无法看到第三方 native 库（如 OpenSSL、Netty 的底层 C 代码）的内存——别指望它包打天下，但它能揪出 90% 的 DirectByteBuffer、Unsafe、JIT 和 GC 内部泄漏。
怎么配 NMT 才算真正生效
NMT 必须在 JVM 启动时开启，运行时无法补救。只加 -XX:NativeMemoryTracking=detail 不够，缺了 -XX:+UnlockDiagnosticVMOptions 会直接报错“Unknown VM option”。生产环境建议先用 summary 级别跑一天，确认性能影响（约 5% CPU 开销）再切 detail。
-
-XX:NativeMemoryTracking=detail：必须，否则看不到Internal（含 DirectBuffer 分配栈）和Other（含 Unsafe、JNI）的明细 -
-XX:+UnlockDiagnosticVMOptions：必须，否则 JVM 启动失败 -
-XX:+PrintNMTStatistics：可选，启动后立刻打印初始内存分布，方便比对 - 避免混用
-Xmx和-XX:MaxDirectMemorySize不匹配——比如设了-Xmx2g却没调MaxDirectMemorySize，默认只有 2g - 堆大小，容易误判为泄漏
jcmd VM.native_memory detail 输出怎么看
重点盯三列：committed（已用物理内存）、reserved（申请的虚拟地址空间）、以及每行末尾的调用栈（detail 模式才有）。committed 持续涨而 reserved 不变，说明是“用一点占一点”，大概率是 DirectByteBuffer 或 MappedByteBuffer 积压；如果 reserved 也同步暴涨，可能是线程栈疯长或 JNI 库反复 mmap。
-
Internal区域里出现大量java.nio.DirectByteBuffer调用栈 → 直接指向allocateDirect()调用点 -
Other区域里有sun.misc.Unsafe或JNI字样 → 检查自定义 native 方法或反射调用Unsafe.allocateMemory() -
Thread的committed持续上升 → 看是否创建了未回收的线程（比如忘了 shutdownExecutorService） - 注意
Java Heap行的committed是堆实际占用，和堆外无关；别把它和 RES 混淆
为什么 baseline + diff 比单次 summary 更可靠
刚启动时 JVM 本身要加载类、预热 JIT、初始化 GC 结构，这些都会占堆外内存。如果只看某次 summary，可能把正常开销当成泄漏。用 jcmd <pid> VM.native_memory baseline</pid> 在服务就绪后打快照，后续用 summary.diff 才能过滤掉“启动噪音”，只暴露真实增长。
- 执行
baseline前，确保应用已完成冷启动（比如 HTTP 接口已成功调通一次、连接池已建连） -
summary.diff scale=MB输出中，只关注committed列为正数的模块，负数是释放，可忽略 - 如果
Internal的 diff 增长 >100MB 且持续数小时不回落，基本坐实 DirectBuffer 泄漏 - diff 不显示调用栈，真要定位代码行，必须用
detail.diff——但它输出极长，建议重定向到文件后 grepDirectByteBuffer
常见陷阱：NMT 显示正常，但 RES 还是狂涨
这通常意味着泄漏源在 JVM 视野之外。NMT 只跟踪 HotSpot 自己调用 malloc/mmap 的行为，不监控：
- Netty 的
PooledByteBufAllocator底层通过 JNI 调用的 native 内存池（需结合 Netty 自带的-Dio.netty.leakDetectionLevel=paranoid） - 数据库驱动（如 PostgreSQL 的 pgjdbc）内部的 native buffer
- Docker 容器内其他进程（比如 sidecar、log-agent）吃掉了内存，却被误认为是 Java 进程
- Linux kernel 的 page cache 或 slab（
cat /proc/<pid>/smaps | grep "^Mapped:"</pid>查映射区域）
这时候得跳出 JVM，用 pstack <pid></pid> 看线程阻塞点、perf record -e syscalls:sys_enter_mmap -p <pid></pid> 抓系统调用，或者直接上 bpftrace 监控 mmap 分配源头——NMT 只是起点，不是终点。
