必须在启动jvm时添加-xx:nativememorytracking=detail，否则无法获取原生内存数据；仅支持off/summary/detail三级，生产环境推荐detail；参数须置于java命令最前，不可写为on或放在-jar后。
启动JVM时必须加-XX:NativeMemoryTracking=detail
不开启NMT，后续所有命令都查不到原生内存数据——它不是默认打开的，也不是运行时能动态启用的。只支持off、summary、detail三级，生产环境建议直接用detail，否则看不到线程栈、mmap区域等关键分类。
常见错误：只加了-XX:+UseG1GC之类参数，忘了开NMT；或写成-XX:NativeMemoryTracking=on（无效值，JVM会静默忽略）。
-
-XX:NativeMemoryTracking=detail必须出现在java命令最前面，不能放在-jar之后 - 开启后JVM启动变慢、内存占用略增（通常
- OpenJDK 8u60+ 和 JDK 9+ 支持，旧版本如 JDK 7 不可用
jcmd <pid> VM.native_memory summary</pid>是最常用诊断入口
这是你发现内存“凭空多出几百MB”时第一个该敲的命令。它不阻塞应用，输出快，能立刻看到总原生内存 vs Java堆的占比关系。
注意：jcmd必须和目标JVM同用户、同JDK版本；如果提示Unable to open socket file，大概率是权限问题或/tmp下hsperfdata_<user></user>目录被清理过。
立即学习“Java免费学习笔记（深入）”；
- 输出里
[thread]过高？说明线程数爆炸或线程栈过大（比如递归太深、栈大小-Xss设得太大） -
[mmap]持续增长？检查是否频繁ByteBuffer.allocateDirect()且没调cleaner，或Netty等框架未正确释放 - 对比
Java Heap和Other项：如果后者远超前者，基本确定是原生层泄漏
用baseline和diff定位增长点
NMT本身不自动采样，必须手动打基线，再比对。没有baseline，就只能看瞬时快照，看不出趋势。
典型误操作：连续执行两次summary以为能看出差异——不行，必须用baseline命令显式记录，再用diff计算差值。
- 先执行
jcmd <pid> VM.native_memory baseline</pid>（建议在应用刚启动、负载平稳时做） - 过一段时间（比如压测后），执行
jcmd <pid> VM.native_memory detail.diff</pid> - 重点关注
committed列变化大的模块，尤其是[class]（动态类加载）、[thread]、[arena]（C++ new/delete分配区） -
detail.diff输出可能很长，用grep -A5 -B5 "committed.*[0-9]M"快速过滤大块变动
别依赖ps aux或pmap判断JVM原生内存
ps aux显示的VIRT和RES包含大量共享库、映射文件、甚至swap预留空间，和JVM实际管理的原生内存不一致；pmap -x <pid></pid>能看到所有mmap，但无法区分哪些是JVM分配、哪些是glibc或驱动占的。
真实场景中，常有运维同学看到RES=2.4G就断定“JVM吃内存”，结果NMT显示原生内存才300MB——其余全是JIT编译代码缓存、ZGC的元数据映射区、或Log4j2的内存映射日志文件。
- JVM的
Committed≈ NMT里各模块committed之和，这个数字才反映JVM主动向OS申请并保证可用的内存 - OS级工具看到的是进程虚拟地址空间全貌，混杂太多非JVM成分
- 如果NMT总和远小于
ps RES，优先检查是否启用了-XX:+UseZGC或-XX:+UseShenandoahGC（它们会预分配大块虚拟内存）
[arena]或[mmap]的线索，找到那一行没配try-with-resources的FileChannel.map()。 
