堆外内存占用过高需用NMT定位：启动加-XX:NativeMemoryTracking=detail，再用jcmd <pid> VM.native_memory summary.diff scale=MB对比变化，重点监控Class、Direct、Thread、Internal四大区域，并结合pmap、jstack、GC日志等交叉验证。
堆外内存（Off-Heap）占用过高，不能只盯着 jstat 或堆转储，因为这些工具对非堆区域完全“看不见”。关键要锁定是 元空间、直接内存、线程栈 还是 NMT 未统计的本地映射，再用对应工具分层验证。
先确认是不是堆外真高了
别被 top 的 RES 值带偏——它包含堆+所有堆外内存。得做减法：
- 用
jstat -gc <pid>算出当前堆已用大小（比如 Eden + S0 + S1 + Old 总和） - 用
pmap -x <pid> | awk '{sum += $3} END {print sum/1024 " MB"}'得到进程总物理内存（RES近似值） - 两者相减，若差值 > 500MB，就值得深挖堆外
用 NMT 定位具体堆外区域
NMT（Native Memory Tracking）是 JVM 自带的堆外内存追踪器，最权威：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 启动时必须加参数：
-XX:NativeMemoryTracking=detail（没开这个，后面全白搭） - 运行中执行：
jcmd <pid> VM.native_memory summary scale=MB，看各模块占比 - 重点盯：Class（元空间）、Internal（JVM内部结构）、Thread（线程栈总和）、Direct（ByteBuffer.allocateDirect）
- 想比变化？执行两次：
jcmd <pid> VM.native_memory summary.diff scale=MB，只显示增长项
分模块针对性排查
根据 NMT 指向的高增长区域，选下一步动作：
立即学习“Java免费学习笔记（深入）”；
-
元空间（Class）暴涨：查动态类生成，如 Spring AOP 代理过多、Groovy 脚本、反复 defineClass；加
-XX:MaxMetaspaceSize=256m并观察是否 OOM，再配合jcmd <pid> VM.class_hierarchy看加载类数量 -
Direct 内存飙升：Netty、Kafka、NIO 框架常用；检查是否
ByteBuffer.allocateDirect()后没调cleaner或free()；开启 Netty 泄漏检测：-Dio.netty.leakDetection.level=paranoid -
Thread 区域过大：说明线程数爆炸；用
jstack <pid> | grep 'java.lang.Thread.State' | wc -l粗略统计线程数；再用ps -T -p <pid> | wc -l看 OS 级线程数是否匹配 -
Internal 或 Unknown 显著增长：可能是 JNI 库（如 JNA、数据库驱动）或 mmap 文件未释放；用
pmap -x <pid>找大块[anon]或.so映射，结合lsof -p <pid>查打开文件
辅助验证：GC 日志与系统工具交叉印证
NMT 是起点，不是终点，需用其他信号交叉验证：
- 开 GC 日志：
-Xlog:gc*:file=gc.log:time,uptime,pid,tags，如果频繁出现Metadata GC Threshold，就是元空间触发回收，佐证 Class 区问题 - 用
cat /proc/<pid>/status | grep VmRSS和VmData对比，VmData 高但堆不大，大概率是 mmap 或 direct buffer - 容器环境加一层：
docker stats <container_id>看 RSS 是否同步上涨，排除宿主机干扰
