堆外内存暴涨需四步定位：先用jstat、top、jmap排除堆内问题；再启用NMT分析增长区域；接着按Direct Buffer、线程、JNI、第三方组件针对性验证；最后通过GC日志、Prometheus监控和代码兜底预防复发。
堆外内存暴涨往往不触发 JVM 堆 OOM，却让进程 RES（常驻内存）持续爬升、系统内存告警，甚至被 OS 杀死（OOM Killer）。它隐蔽性强、不走 GC，必须用专门手段定位。
第一步：确认是不是堆外内存问题
别一上来就 dump 堆 —— 先排除堆内干扰：
- 用 jstat -gcutil <pid> 2s 观察 OU（老年代使用率）：如果长期稳定、Full GC 后能回落，基本排除堆泄漏；
- 用 top -p <pid> 看 RES 值，再对比 jmap -heap <pid> 显示的 committed heap 大小。若 RES 比堆大 1G 以上（比如堆 2G，RES 4.5G），大概率是堆外在吃内存；
- 检查 Metaspace 使用：jstat -gcmetacapacity <pid>，看 MC/MU 是否持续增长，排除动态类加载导致的元空间膨胀。
第二步：启用并分析 Native Memory Tracking（NMT）
NMT 是诊断堆外内存最直接、最可靠的官方手段：
- 启动时加参数：-XX:NativeMemoryTracking=detail（生产环境慎用，有约 5% 性能损耗，但排查期值得）；
- 运行一段时间后执行：jcmd <pid> VM.native_memory summary.diff（需先执行一次 baseline，再过几小时再执行一次，diff 才有意义）；
- 重点关注增长最快的区域：Internal（JVM 内部结构）、Thread（线程数过多或栈过大）、Direct（ByteBuffer.allocateDirect）、Code（JIT 编译缓存）、Class（类加载未卸载）。
第三步：针对性验证与定位
根据 NMT 提示方向，做进一步验证：
-
Direct Buffer 泄漏：查代码是否频繁调用
allocateDirect()且未调用cleaner或free()；可通过 JMX 查java.nio:type=BufferPool,name=direct的TotalCapacity和Count，观察是否只增不减； - 线程爆炸：用 jstack <pid> | grep "java.lang.Thread" | wc -l 统计线程数，再结合 pstack <pid> | head -20 看是否有大量相似栈帧（如 Netty EventLoop、自定义线程池未 shutdown）；
-
JNI 或本地库泄漏：用 pmap -x <pid> 查看各内存段大小和映射来源，特别关注
[anon]区域是否异常庞大；配合 gdb <pid> 或 valgrind --tool=memcheck（需预编译支持）深入追踪 C/C++ 层分配； - 第三方组件堆外行为：常见于 Netty（PooledByteBufAllocator）、RocketMQ（MappedByteBuffer）、Elasticsearch（off-heap cache）、Log4j2（AsyncLogger disruptor ring buffer），查阅对应组件文档确认其堆外内存配置与释放逻辑。
第四步：监控与预防落地
单次排查解决不了反复问题，要建立可持续防线：
- 在 JVM 启动参数中固定加入：-XX:+PrintGCDetails -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，GC 日志里可间接反映堆外压力（如 Full GC 频次突增可能因 Direct Buffer 回收触发）；
- 用 Prometheus + JMX Exporter 暴露关键指标：
java.nio.BufferPool.direct.*、java.lang:type=MemoryPool,name=Metaspace.Usage.used、java.lang:type=Threading.TotalStartedThreadCount，设置告警阈值； - 对高风险操作强制兜底：如使用
try-with-resources包裹 DirectByteBuffer（需封装为 AutoCloseable）、限制线程池 core/max size、禁用无界队列、关闭未使用的 Netty PooledAllocator。
