关键在于确认native内存耗尽：查dmesg锁定oomkiller日志，用pmap看anon区增长，结合nmt detail定位malloc未释放点，并排查directbytebuffer、第三方库资源及c++内存配对问题。

排查JNI调用中C/C++代码未释放内存导致的“堆外暴死”（即进程因虚拟内存耗尽被系统OOM Killer强制终止），关键在于确认泄漏发生在Native堆而非Java堆，并快速定位到具体分配点。这类问题不抛Java异常，常表现为进程静默退出、dmesg日志出现"Out of memory: Kill process"，且jstat或jmap显示Java堆正常。

看系统级证据，确认是Native内存耗尽

先排除误判，聚焦真实堆外暴死信号：

• 查dmesg -T | grep -i "killed process"：若输出含"java"和"out of memory"，基本锁定Native内存超限；
• 用pmap -x <pid></pid>观察进程内存映射：重点关注anon（匿名映射）和[heap]区域持续增长，而[stack]或[vdso]无异常；
• 对比/proc/<pid>/status</pid>中VmRSS（物理内存）与VmSize（虚拟内存）：若VmSize飙升至数GB甚至10GB+，而VmRSS远低于它，说明大量mmap或malloc未释放，占满地址空间。

用NMT detail追踪malloc源头

NMT（Native Memory Tracking）是JVM原生支持的唯一可靠手段，必须启用detail模式：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 启动JVM时加参数：-XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions；
• 在疑似泄漏后执行：jcmd <pid> VM.native_memory detail | grep -A 5 -B 2 "libxxx\.so\|Java_com_.*"</pid>（替换libxxx.so为你自己的库名）；
• 重点盯三列：malloc=SIZE（单次大小）、#N（累计次数）、调用栈中是否含你的C++函数名；
• 若某函数的#N持续上升，且无对应free=记录，就是泄漏点——注意：编译so时必须保留符号表（-g），否则栈里只显示地址偏移。

结合Android或Linux专用工具交叉验证

尤其在Android平台，NMT可能受限，需补充外部工具：

• Android上启用adb shell dumpsys meminfo <package></package>，关注Native Heap字段是否随操作线性上涨；
• 开发阶段用AddressSanitizer（ASan）编译so：-fsanitize=address -fno-omit-frame-pointer，运行时报错直接带泄漏堆栈；
• 线上环境可用gperftools（tcmalloc）：LD_PRELOAD注入后生成pprof报告，pprof --inuse_space可直观看到未释放内存的分配点。

检查高频泄漏模式，直击典型场景

80%的堆外暴死源于以下三类硬编码错误：

• DirectByteBuffer未清理：频繁allocateDirect()但未触发Cleaner回收，或手动调用cleaner.free()失败；
• 第三方native库资源未关闭：如Netty epoll channel未close()、SQLite statement未sqlite3_finalize()、OpenCV Mat::release()遗漏；
• C++ new/malloc后无配对delete/free：尤其在异常分支、循环体或回调函数中，容易跳过释放逻辑。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南