如何追踪JVM原生内存？NMT无法定位泄漏的排查方法

NMT仅能覆盖HotSpot虚拟机自身的内存分配逻辑，确实无法追踪第三方原生代码、JDK类库中直接调用系统内存接口产生的分配，以下是经过生产验证的可覆盖全场景的排查方案：

• 替换内存分配器做分配采样（推荐生产环境使用）
  绝大多数原生内存分配最终都会经过内存分配器的malloc/free接口，替换默认glibc malloc为带profiling能力的分配器即可无侵入追踪所有分配行为，性能损耗通常低于5%：

  1. 以jemalloc为例，启动Java进程前配置环境变量：

     export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so
     export MALLOC_CONF=prof:true,prof_active:true,lg_prof_sample:19,prof_prefix:/tmp/native_leak_prof
     

  2. 进程运行后会按配置自动生成内存分配快照，使用jemalloc自带的jeprof工具对比不同时间点的快照差异，即可定位到持续增长、未释放的内存块对应的完整调用栈，可直接定位到第三方so库、JDK native方法的具体分配位置。
     tcmalloc的使用逻辑类似，自带的heap profiler也可实现相同效果。

• glibc原生malloc追踪（适合测试环境复现定位）
  无需额外安装依赖，直接利用glibc自带的调试能力即可追踪所有内存分配：

  1. 启动前加载glibc的malloc调试库，开启mtrace记录：

     export LD_PRELOAD=/lib/x86_64-linux-gnu/libc_malloc_debug.so
     export MALLOC_TRACE=/tmp/mtrace.log
     

  2. 进程运行过程中mtrace会记录所有malloc/free的调用栈，待内存涨到高位后，使用系统自带的mtrace工具分析日志，即可过滤出所有未释放的内存块对应的调用栈。如果是简单的内存越界类问题，配置export MALLOC_CHECK_=2即可直接触发报错定位问题点。

• JVM层面针对性排查（适配JDK类库堆外分配场景）
  针对JDK类库常见的原生内存泄漏点（比如NIO DirectByteBuffer、zip/defalter相关类），无需做系统层面配置即可排查：

  1. 增加JVM启动参数-XX:MaxDirectMemorySize=实际预期的直接内存阈值 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，触发直接内存OOM时会自动dump堆快照，用MAT等工具分析堆内的DirectByteBuffer等堆外内存对象的引用链，即可定位到未释放的对象来源。
  2. 若怀疑是JNI调用产生的泄漏，可通过JVMTI开发简单的代理，挂钩JNI标准接口中所有内存分配、释放的方法（比如NewGlobalRef、DeleteGlobalRef、malloc相关调用封装），记录每次分配的Java侧调用栈、内存地址，定期统计未释放的分配块即可定位。

• 动态追踪工具（线上应急无重启排查）
  对于已经在运行的线上进程，无法重启配置环境变量时，可使用系统自带的动态追踪工具无侵入排查：

  1. Linux环境下使用bpftrace或perf，挂钩malloc、free、mmap、munmap等系统调用和libc函数，按调用栈聚合对应Java进程的内存分配大小，持续观察一段时间，找到内存持续增长对应的栈帧即可定位，这类工具的采样开销极低，不会对业务造成明显影响。
  2. Windows环境下可使用系统自带的UMDH工具，抓取进程不同时间点的用户态堆分配快照，对比快照差异即可找到泄漏的调用栈。

注意：所有带调用栈采集的追踪方案都存在一定性能开销，生产环境使用前务必先在测试环境验证，合理设置采样率，避免影响业务正常运行。

内容的提问来源于stack exchange，提问作者henry-jo