堆外内存泄漏排查核心在于RSS持续上涨而堆内存稳定，需通过kubectl top、jstat、ps确认现象，再用NMT定位Internal/Direct/Thread等模块增长，结合pmap/smaps分析系统级内存页，并最终溯源至allocateDirect、JNI或NIO框架代码。
堆外内存泄漏排查的核心在于：它不发生在Java堆里，所以堆dump完全“看不见”问题，但JVM进程的RSS（实际物理内存）却在持续上涨，最终被K8s OOM Killer干掉。排查不是靠猜，而是从现象出发，用系统级+JVM级工具交叉验证，层层缩小范围。
先确认是不是堆外泄漏，而不是堆内问题
看到容器OOM重启，别急着分析堆dump——先看三个关键指标：
- 用 kubectl top pods 查容器内存使用率，是否远超 -Xmx 设置值（比如堆设4G，RSS已到14G）
- 用 jstat -gc PID 看老年代使用率（O列）是否稳定在低位（如
- 用 ps aux | grep java 或 cat /proc/PID/status | grep VmRSS 确认进程RSS是否持续单向增长
三者同时满足，基本可锁定堆外内存异常增长。
查JVM堆外内存分配主体：用Native Memory Tracking（NMT）
NMT是JVM内置的堆外内存追踪开关，必须启动时开启（-XX:NativeMemoryTracking=summary 或 detail）。运行中执行：
立即学习“Java免费学习笔记（深入）”；
- jcmd PID VM.native_memory summary —— 快速看各模块内存占比（重点关注 Internal、Direct、Mapped、Thread）
- 若 Direct 内存持续上升，大概率是 ByteBuffer.allocateDirect() 没释放或复用不当
- 若 Thread 模块增长明显，检查是否线程数失控（如未用线程池、线程未join/destroy）
- 若 Internal 占比高，可能与JIT编译缓存、JVM内部结构（如StringTable）或某些JNI库有关
绕过JVM看操作系统：用pmap和smaps定位真实内存页
JVM只是用户进程，Linux才管真正的物理内存。进入容器后：
- pmap -x PID | tail -20 —— 查看最大的几十块内存映射区，看是否有大量64MB/128MB等固定大小的anon区域（典型直接内存块）
- cat /proc/PID/smaps | grep -A 5 -B 5 "7f.*rw..[0-9a-f]" | grep -E "(Size|MMU|AnonHugePages)" —— 找大块匿名内存页，确认是否归属Java进程
- 结合 ls -l /proc/PID/fd/ | grep socket 或 lsof -p PID | wc -l 排查文件描述符泄漏（也会吃RSS）
结合代码和依赖定位根因
工具只能指出“哪类资源涨了”，最终要落到代码：
- 搜项目中所有 allocateDirect 调用，确认是否复用Buffer、是否调用 cleaner 或 free()（JDK 21+需显式close）
- 检查JSON序列化框架（如Fastjson、Jackson）是否启用全局缓存、是否禁用循环引用检测（易触发大量临时DirectBuffer）
- 审查Netty、gRPC等NIO框架配置：maxDirectMemory 是否合理？PooledByteBufAllocator 是否启用？
- 留意JNI调用：自定义.so库是否申请内存后未释放，或回调Java对象导致引用无法回收
不复杂但容易忽略
