堆外内存泄漏指Java应用在堆外持续分配未释放内存，导致RSS持续上涨而堆内存正常；典型表现为top中RES飙升、jstat显示老年代使用率低且无Full GC，最终被OOM Killer杀掉进程。
堆外内存泄漏是指Java应用在堆以外的本地内存中持续分配却未释放，导致进程RSS（物理内存占用）不断上涨，而堆内存监控（如jstat、JMX）却显示一切正常。这类问题不会抛出OutOfMemoryError，但会悄悄耗尽系统内存，最终被Linux OOM Killer强制杀掉进程。
堆外内存泄漏的典型表现
最直观的信号是：top或ps看到Java进程RSS从2GB涨到10GB，但jstat -gc显示老年代使用率始终低于40%，GC频率低且无Full GC。同时服务响应变慢、容器频繁重启，日志里却找不到OOM相关异常。
- 元空间（Metaspace）持续增长：大量动态生成类（如Spring AOP代理、Groovy脚本、JSON反序列化）未卸载
- DirectByteBuffer堆积：NIO网络框架（如Netty）中ByteBuffer.allocateDirect()后未调用cleaner或未显式调用buffer.clear()/buffer = null
- 线程数失控：每个线程默认占1MB栈空间，线程泄漏（如未关闭的Executors、未shutdown的ScheduledThreadPool）直接推高RSS
- JIT代码缓存膨胀：高频反射调用或Lambda频繁生成导致Code Cache打满
启用NMT进行基础监控
NMT是HotSpot JVM自带的诊断工具，无需额外依赖。启动时加参数即可开启：
-
生产环境推荐：
-XX:NativeMemoryTracking=summary（性能开销约1–3%） - 定位具体泄漏点时用：
-XX:NativeMemoryTracking=detail（需重启，开销5–10%，记录调用栈） - 搭配
-XX:+UnlockDiagnosticVMOptions才能使用jcmd触发命令
启动后等待应用运行10–30分钟，确保各组件完成初始化，再执行快照采集。
立即学习“Java免费学习笔记（深入）”；
用jcmd分析内存分布
通过jcmd获取实时内存报告，重点关注非堆区域的“committed”值是否持续上升：
- 查当前汇总：
jcmd <pid> VM.native_memory summary scale=MB - 对比两次快照差异：
jcmd <pid> VM.native_memory summary.diff scale=MB（需先执行baseline） - 看详细调用栈（仅detail模式支持）：
jcmd <pid> VM.native_memory detail.scale=MB
重点观察Internal、Direct、Thread、Metaspace这几项committed值的变化趋势。比如Direct项从50MB升至2GB，基本可锁定DirectByteBuffer泄漏。
结合现象快速定位常见泄漏源
拿到NMT报告后，按区域交叉验证：
- Direct项飙升 → 检查Netty、Kafka客户端、自定义NIO代码，确认所有allocateDirect()都有对应release逻辑
-
Thread项上涨 → 执行
jstack <pid> | grep java.lang.Thread | wc -l统计线程数，比对jcmd中Thread数量是否一致 -
Metaspace持续增长 → 加
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察是否频繁触发Metaspace GC；检查是否有ClassLoader未释放 - Internal项异常高 → 多为JNI库或第三方SDK（如图像处理、加密库）内部malloc未free，需联系厂商或换版本
不复杂但容易忽略的是：NMT本身不捕获应用层直接调用System.loadLibrary后的malloc，这部分需配合pmap或gdb进一步排查。
