pmap -x是定位内存泄漏的起点，因它唯一提供rss和dirty两列关键数据；pid必须为数字，可用pgrep -f或systemctl show获取；mapping列中重点排查[heap]、[anon]及共享库分段的rss异常增长。
看 pmap -x 找匿名内存块膨胀点
堆不大但进程 RSS 高，大概率是堆外内存（native memory）在涨。Linux 进程的物理内存占用（top 里的 RES）包含堆、元空间、线程栈、DirectByteBuffer、JNI 分配、mmap 映射等，而这些全体现在 pmap -x <pid></pid> 的输出里。
重点关注两列：RSS（实际占用物理内存）和 Mapping 列为 [anon] 的行——这类匿名映射段就是 JVM 或 native 代码通过 malloc/mmap(MAP_ANONYMOUS) 申请的堆外内存。
- 执行
pmap -x <pid> | sort -nrk3 | head -20</pid>，看前 20 大[anon]块是否集中于某固定大小（比如大量 64M、128M 块），这很可能是 Netty 的PooledByteBufAllocator或自定义 native buffer 池未释放 - 对比两次采样：
pmap -x <pid> > pmap_1.txt</pid>，隔几分钟再跑一次存为pmap_2.txt，用diff pmap_1.txt pmap_2.txt看哪些[anon]段变大了或新增了 - 若发现
libjvm.so映射区域 RSS 异常高（远超 100MB），可能是 JVM 内部 native 结构（如 G1 的 remembered set、ZGC 的 metadata）膨胀，需结合 GC 日志判断
查 jcmd <pid> VM.native_memory</pid> 确认 native 内存分类
VM.native_memory 是 JDK 7u40+ 提供的 native 内存统计入口，能按类别拆解 JVM 自身使用的 native 内存（不包含第三方 JNI 或直接 mmap）。前提是启动时加了 -XX:NativeMemoryTracking=summary（JDK 8u60+ 默认支持，但需显式开启）。
- 执行
jcmd <pid> VM.native_memory summary</pid>，看Internal、Class、Thread、ChunkPool等项是否持续增长；其中Thread高说明线程数多或栈过大（-Xss设置偏高），Internal高可能指向DirectByteBuffer或Unsafe.allocateMemory泄漏 - 若返回
Native memory tracking is not enabled，说明没开 NMT，此时只能靠pmap+cat /proc/<pid>/maps</pid>辅助定位 - NMT 的
detail模式（jcmd <pid> VM.native_memory detail</pid>）会输出调用栈，但开销大、仅建议短时开启用于抓快照
盯 DirectByteBuffer 和 MappedByteBuffer 实例数
JVM 堆内对象少，但堆外缓存（尤其 Netty、NIO 文件读写、零拷贝场景）容易失控。这些 buffer 对象本身很小（堆内只存一个 Cleaner 引用），但背后 native 内存可能几十 MB。
- 用
jmap -histo:live <pid> | grep -i "bytebuffer\|cleaner"</pid>查看java.nio.DirectByteBuffer、sun.nio.ch.DirectBuffer、java.lang.ref.Finalizer（旧版 JDK）或jdk.internal.ref.Cleaner（JDK 9+）实例数是否异常多 - 若
DirectByteBuffer实例数稳定但rss持续涨，说明 buffer 没被及时回收（常见于未调用buffer.clear()/buffer.flip()导致引用链未断，或Cleaner被阻塞） - 检查代码中是否用了
FileChannel.map()创建大块MappedByteBuffer却未显式cleaner.clean()（需反射调用，不推荐）或依赖 GC 触发 —— 这种映射在 GC 前不会释放，且 GC 不保证及时性
别忽略线程栈和 MaxMetaspaceSize 配置
线程和类元数据这两块“非堆但非 native”的内存，常被误认为堆外泄漏，其实它们有明确配置边界，排查优先级高但修复成本低。
- 线程栈：每个线程默认栈大小由
-Xss控制（JDK 8 默认 1MB，JDK 11+ 默认 1MB，alpine 可能更小）。用ps -T -p <pid> | wc -l</pid>看线程总数，乘以-Xss值即理论栈内存上限；若线程数达数百甚至上千，即使单个栈小，总量也很可观 - 元空间：若未设
-XX:MaxMetaspaceSize，JVM 会动态扩容直到 OOM；用jstat -gc <pid></pid>看MU（metaspace used）是否持续上涨且接近MC（metaspace capacity）；线上必须显式限制，例如-XX:MaxMetaspaceSize=256m - 容器环境注意：JDK 8 需手动加
-XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0，否则 JVM 可能按宿主机内存算堆，但元空间/线程栈仍按默认值分配，导致容器内存超限
真正难啃的是那些不走 JVM 管理路径的 native 内存：JNI 库未释放资源、C++ 代码 malloc 后忘 free、glibc 的 malloc arena 碎片化（表现为 [anon] 块多但单个不大）、甚至 jemalloc/tcmalloc 替换后行为差异。这类问题必须结合 pstack、gdb attach 或 perf record -e syscalls:sys_enter_mmap 追踪系统调用才能定位，日常排查先守住 JVM 自身可配可控的部分。
