WEBKT

JVM 查不出来的内存泄漏：JNI 穿透与 Valgrind 实战排查指南

3 0 0 0

在 Java 开发中，内存泄漏通常伴随着 java.lang.OutOfMemoryError（OOM）和频繁的 Full GC。借助 MAT、JProfiler 或 VisualVM 等工具，我们能很方便地通过引用链（GC Roots）定位到泄漏源头。

然而，当 Java 应用引入了 JNI（Java Native Interface），调用了 C/C++ 编写的动态链接库时，内存世界就分裂成了两部分：JVM 堆（Java Heap）与本地堆（Native Heap）。JNI 层的内存泄露是 JVM 监控工具的盲区，表现形式诡异，排查难度极高。

本文将深度对比 JNI 内存泄漏（包括本地方法栈和本地堆泄漏）与常规 Java 堆泄漏在表现上的本质区别，并详解如何利用 Linux 下的系统级调试利器 valgrind 定位 JNI 内存泄漏。

一、JNI 内存泄漏 vs Java 堆泄漏：表现上的本质区别

要排查问题，首先得学会诊断。JNI 导致的内存问题与 JVM 内部的内存问题在系统层面的表象截然不同。

维度的对比 Java 堆内存泄漏 (Java Heap Leak) JNI / Native 内存泄漏 (Native Leak)
内存区域 JVM 堆区（Heap） 进程的本地堆（C-Heap）、本地方法栈（Native Stack）
垃圾回收（GC）表现 随着内存上升，GC 频率极高，每次 GC 后释放内存微乎其微，最终演变为持续的 Full GC。 JVM 认为堆内存非常健康，GC 频率正常，甚至根本不触发 GC。
报错特征 抛出 java.lang.OutOfMemoryError: Java heap space 或 GC overhead limit exceeded。 进程直接被系统内核 OOM Killer 强杀（Killed），或 JVM 崩溃输出 hs_err_pid.log，提示 native allocator out of memory。
监控工具表现 jstat、jconsole 明显看到 Heap 占用率呈锯齿状爬升直至封顶。 jstat 显示 Java 堆很空闲，但系统命令 top 或 pmap 显示该进程的 RSS（物理内存） 和 VSZ（虚拟内存） 持续暴涨。
代码诱因 长生命周期对象（如静态 Map）持有短生命周期对象的引用，导致 GC 无法回收。 1. 未调用对应的 ReleaseX 方法（如 GetStringUTFChars 后未 Release）；
2. 局部引用（LocalRef）在循环中爆棚且未主动释放；
3. C/C++ 层面 malloc/new 的内存未 free/delete。

特殊的“本地方法栈溢出”

JNI 还会引发另一种栈溢出。Java 虚拟机栈用于管理 Java 方法的调用，而**本地方法栈（Native Method Stack）**用于支持 Native 方法的调用。

  • 如果 JNI C/C++ 代码中存在递归死循环，或者在栈上分配了极大的局部变量（如 char buf[1024 * 1024 * 10]），会直接导致本地方法栈溢出。
  • 表现为进程立即崩溃，收到系统信号 SIGSEGV (Segmentation fault)，并在 JVM 崩溃日志中看到类似 Instruction indicating signature: ... 发生在非 Java 帧上。

二、典型的 JNI 泄漏代码示例

在开始使用 valgrind 调试之前，我们先看一段经典的 JNI 泄露代码。

1. Java 端声明

public class NativeLib {
    static {
        System.loadLibrary("leaky_jni");
    }
    public native void processData(String input);
}

2. C++ 端实现 (libleaky_jni.cpp)

#include <jni.h>
#include <stdlib.h>
#include <iostream>

extern "C"
JNIEXPORT void JNICALL Java_NativeLib_processData(JNIEnv *env, jobject obj, jstring input) {
    // 泄漏源 1：获取 JVM 字符串，但忘记释放
    const char *str = env->GetStringUTFChars(input, nullptr);
    std::cout << "Processing: " << str << std::endl;
    // 应该调用 env->ReleaseStringUTFChars(input, str); 却遗漏了

    // 泄漏源 2：原生的 C++ 堆内存泄漏
    char* nativeBuffer = (char*)malloc(2048); // 每次调用分配 2KB
    sprintf(nativeBuffer, "Formatted: %s", str);
    // 忘记 free(nativeBuffer);
}

当该方法在 Java 端被高频循环调用时，本地堆（Native Heap）会以每秒数兆的速度流失，而 JVM 的垃圾回收器对此完全无能为力。

三、使用 Valgrind 定位 JNI 内存泄漏

valgrind 是一款 Linux 下极其强大的内存调试与分析工具，其中的 memcheck 工具能够拦截所有 malloc/free/new/delete 调用，记录内存分配的调用栈，从而精准指出哪一行代码分配了内存却未释放。

由于 JVM 自身在启动和运行过程中会进行大量的底层内存操作（包括自建内存池、JIT 编译、GC 标记等），直接使用 Valgrind 调试 Java 进程会产生海量的“伪报”（False Positives）。因此，我们需要针对 JVM 进行特殊配置。

步骤 1：准备调试环境

首先，确保你的 JDK 带有调试符号。如果使用的是生产环境的 OpenJDK，建议安装带有 debug symbols 的版本（例如在 Ubuntu 上安装 openjdk-11-dbg），否则 Valgrind 打印出的 JVM 内部调用栈将全是十六进制地址。

步骤 2：编写 Valgrind 过滤文件 (Suppression File)

为了屏蔽 JVM 自带的非泄漏内存分配警报，我们需要使用 Valgrind 的 suppressions 机制。创建一个名为 jvm.supp 的文件。

你可以从 OpenJDK 社区或一些开源项目中获取标准的 jvm.supp，一个基础的过滤模板如下：

{
   JVM_Internal_Leaks
   Memcheck:Leak
   match-leak-kinds: possible, reachable
   fun:*
   obj:*/libjvm.so
}
{
   Java_Read_Undefined_Value
   Memcheck:Value8
   obj:*/libjvm.so
}

提示：实际操作中，如果只想关注我们自己写的动态库，可以通过过滤条件把范围收窄到我们的 .so 文件上。

步骤 3：启动 Valgrind 进行监测

使用以下命令启动 Java 程序（建议在测试/预发环境运行，因为 Valgrind 会使程序运行速度变慢 10 到 50 倍）：

valgrind --tool=memcheck \
         --leak-check=full \
         --show-leak-kinds=all \
         --undef-value-errors=no \
         --log-file=valgrind_report.log \
         java -cp . -Djava.library.path=. NativeLibTest

关键参数解释：

  • --tool=memcheck：启用内存检测工具。
  • --leak-check=full：在程序退出时，展示详细的泄露点（具体到代码行号）。
  • --show-leak-kinds=all：展示所有类型的泄漏（明确泄漏、间接泄漏、可能泄漏等）。
  • --undef-value-errors=no：禁用未初始化变量的使用警告。JVM 在执行 JIT 编译的代码时经常会有这类操作，关闭它可以大幅减少噪音。
  • --log-file=valgrind_report.log：将极为详尽的日志输出到指定文件。

步骤 4：触发泄漏并分析报告

运行 Java 测试用例，触发 JNI 方法调用。运行一段时间后，优雅地关闭 Java 进程（发送 SIGTERM 或正常退出，切勿使用 kill -9，否则 Valgrind 无法生成最终的泄漏报告）。

打开 valgrind_report.log，搜索我们自己的动态库名称（例如 libleaky_jni.so），你会看到类似如下的黄金排查线索：

==12345== 2,048 bytes in 1 blocks are definitely lost in loss record 512 of 1,024
==12345==    at 0x4C29F73: malloc (vg_replace_malloc.c:309)
==12345==    by 0x7F3A1234: Java_NativeLib_processData (libleaky_jni.cpp:13)
==12345==    by 0x15B2C3D1: ??? (An intermediate JNI call frame generated by JVM)
==12345==    by 0x15B15A02: ???
==12345==    ...

报告解读：

  • 2,048 bytes in 1 blocks are definitely lost：明确有 2KB 内存丢失。
  • at 0x4C29F73: malloc ...：这块内存是通过 malloc 分配的。
  • by 0x7F3A1234: Java_NativeLib_processData (libleaky_jni.cpp:13)：重点来了！承载分配行为的代码位于 libleaky_jni.cpp 的第 13 行。
  • 后面的 ??? 则是 JVM 内部动态生成的 JNI 桥接指令，我们可以忽略。

至此，泄漏位置被精准锁定。

四、如何优雅地避免 JNI 内存泄漏？

排查是治标，规范编码才是治本。在编写 JNI 代码时，务必遵循“谁申请，谁释放”的对称原则：

  1. JNI 局部引用限制：JNI 函数内创建的 jobject、jstring、jclass 等属于局部引用（LocalRef），虽然在 Native 方法返回 JVM 后会自动释放，但在高频循环中，必须显式调用 env->DeleteLocalRef(local_ref)，否则很容易在方法返回前撑爆 LocalRef 表（默认上限通常只有 512 个）。
  2. 字符串与数组的对等释放：
    • GetStringUTFChars 对应 ReleaseStringUTFChars
    • GetByteArrayElements 对应 ReleaseByteArrayElements
  3. C++ 智能指针的使用：在 Native 内部，尽量使用 std::unique_ptr 或 std::shared_ptr 管理原生内存，利用 C++ 的 RAII 机制，避免因提前 return 或抛出异常而跳过 free。
码农深渊 JNI内存泄漏Valgrind

评论点评