Java 堆外内存泄漏排查：利用 eBPF (BCC) 追踪内核级与用户态分配调用栈

2026/6/28 04:32:35 3 0 0 0

在 Java 应用的生产实践中，最让人头疼的问题之一莫过于非堆内存（Off-Heap Memory）持续增长，甚至导致 OOM 被 Linux 内核的 Out-Of-Memory Killer 强行杀死。

传统的 JVM 工具（如 jmap、jstack、jcmd）对堆外内存往往束手无策，因为它们主要关注 JVM 堆内（Heap）以及 JVM 自身管理的内存区（如 Metaspace）。当通过 JNI、Unsafe、DirectByteBuffer、或者是第三方本地库（如 Netty 的 Epoll 实现、Gzip/Zip 解压、Cryptography 加密）直接调用系统底层的 malloc 或 mmap 申请内存时，JVM 工具链就“失明”了。

虽然可以使用 gperftools 或 jemalloc 进行 Profiling，但它们需要通过 LD_PRELOAD 强行侵入应用启动过程，在生产环境伴随着不小的风险和性能损耗。

本文将介绍如何利用 eBPF（Extended Berkeley Packet Filter） 这一现代 Linux 内核观测利器，在不重启 Java 进程、极低性能开销的前提下，精准捕获并还原 Java 堆外内存在 Linux 内核与 Glibc 层面的分配调用栈。

一、核心痛点：为什么排查 Java 堆外内存这么难？

当我们在 Linux 上排查 Java 堆外内存泄漏时，主要面临三大挑战：

调用栈断层（Frame Pointer Omission）：X86-64 架构上，默认编译参数通常会启用 -fomit-frame-pointer（优化掉帧指针 RBP 寄存器）。这导致普通的栈回溯工具（如 pstack）无法正确还原用户态的调用栈，抓出来的栈全是乱码。
JIT 动态编译符号缺失：Java 代码是被 JIT 动态编译成机器码的，其方法地址在常规的 ELF 符号表中根本不存在。eBPF 抓取到用户态地址后，无法直接将其还原为 com.example.Foo.bar() 这样的 Java 类名和方法名。
高频分配的性能开销：如果直接去 Hook malloc / free 这种高频调用的函数，会导致严重的性能抖动。

为了彻底解决这些痛点，我们需要进行一套组合拳操作。

二、前置准备工作

在开始使用 eBPF 工具之前，必须让 JVM 暴露必要的调试信息。

1. 开启 JVM 帧指针（Frame Pointer）

为了让 eBPF 能够正确回溯 Java 的调用栈，必须在 Java 启动参数中加入以下参数。这一步是成功获取清晰调用栈的关键：

-XX:+PreserveFramePointer

注：该参数在 JDK 8u60 之后引入，性能损耗极低（通常小于 1%），建议在线上生产环境默认开启，便于随时排查性能问题。

2. 生成 JIT 符号表映射文件（Perf Map）

由于 eBPF 运行在内核态，它在解析用户态虚拟地址时，需要读取 /tmp/perf-<PID>.map 文件来完成 JIT 编译方法的符号映射。

我们可以使用开源工具 perf-map-agent 动态生成此文件，而无需重启 JVM：

# 下载并编译 perf-map-agent
git clone https://github.com/jvm-profiling-tools/perf-map-agent.git
cd perf-map-agent
cmake .
make

# 为目标 Java 进程生成符号表（假设 PID 为 12345）
bin/create-java-perf-map.sh 12345

执行后，会在 /tmp/ 目录下生成一个 /tmp/perf-12345.map 文件。eBPF 工具（如 BCC 和 perf）会自动加载该文件来解析 Java 栈。

三、实战演练：使用 BCC 的 `memleak` 定位泄漏

BCC（BPF Compiler Collection）提供了一个现成的工具 memleak，它可以监控指定进程的用户态内存分配（malloc、calloc、realloc、mmap 等），并定期打印出未释放的内存分配调用栈。

1. 启动观测

假设我们的 Java 进程 PID 为 12345，我们希望找出那些分配了但长期未释放（例如超过 30 秒）的堆外内存。

运行以下命令：

/usr/share/bcc/tools/memleak -p 12345 -t --older 30000 -U

关键参数解析：

-p 12345：指定观测的 Java 进程 PID。
-t：打印每次分配的时间戳。
--older 30000：只关注分配时间超过 30,000 毫秒（30秒）且未被释放的内存。这能有效过滤掉那些生命周期极短的正常临时分配。
-U：打印用户态（User Space）的调用栈。因为 Java 的分配源头在用户态，所以这个参数至关重要。

2. 结果分析与调用栈还原

运行一段时间后，memleak 会输出类似下面的堆栈信息：

[14:23:45] Allocating address 0x7f81bc012000 with age 45012 ms
        [0x7f82701b2a30] malloc+0x40 [libc-2.27.so]
        [0x7f8221054a12] Java_java_util_zip_Inflater_init+0x52 [libzip.so]
        [0x7f81bc2014d5] <unresolved> [/tmp/perf-12345.map]
        [0x7f81bc203f10] <unresolved> [/tmp/perf-12345.map]

如果看到类似 <unresolved> 的输出，说明由于某些原因 perf-12345.map 文件未能被 BCC 正确读取，或者地址发生了漂移。

为了获得完美的 Java 栈，我们可以手动将十六进制地址与 /tmp/perf-12345.map 进行匹配。

打开 /tmp/perf-12345.map，其格式通常为：

7f81bc201400 1f0 Lcom/example/utils/ZipCompressor;::decompress
7f81bc203e80 2d0 Lcom/example/service/DownloadService;::handleRequest

通过简单的地址范围检索（例如 0x7f81bc2014d5 落在 7f81bc201400 到 7f81bc201400 + 0x1f0 之间）：

0x7f81bc2014d5 -> com.example.utils.ZipCompressor.decompress
0x7f81bc203f10 -> com.example.service.DownloadService.handleRequest

由此，我们精准抓出了元凶：在 DownloadService.handleRequest 中调用 ZipCompressor.decompress 时，由于没有显式调用 Inflater.end() 释放 native 资源，导致了 libzip.so 内部 malloc 的内存发生泄漏！

四、进阶演练：使用 `bpftrace` 降低观测开销

memleak 底层基于 uprobes 拦截 malloc / free。如果目标 Java 应用的吞吐极高，QPS 达到数万，那么频繁触发用户态探针（uprobe）会带来显著的 CPU 上下文切换开销。

为了解决这个问题，我们可以采取降维打击策略：不在用户态 Hook 每一个小内存分配，而是在内核态 Hook mmap / brk 系统调用。因为 Glibc 最终也是通过这两个系统调用向内核申请大块虚拟内存页的。

编写一个名为 trace_java_mmap.bt 的 bpftrace 脚本：

#!/usr/bin/env bpftrace

tracepoint:syscalls:sys_enter_mmap
/pid == $1/
{
    // 记录分配长度
    @mmap_sizes[ustack] = sum(args->len);
}

interval:s:10
{
    printf("--- Past 10 seconds top mmap allocators ---\n");
    print(@mmap_sizes, 10);
    clear(@mmap_sizes);
}

运行此脚本（传入 Java 进程 PID）：

bpftrace trace_java_mmap.bt 12345

该方法的优势在于：

零性能损耗：mmap 的调用频次远低于 malloc，性能开销几乎可以忽略不计，非常适合直接在超大规模生产集群上进行常态化监控。
直击本质：DirectByteBuffer 申请大块堆外内存时，底层最终必然调用 mmap。通过此脚本能一眼看清是哪个 Java 调用栈在大量蚕食系统虚拟地址空间。

五、典型 Java 堆外内存泄漏场景及排查特征

在通过 eBPF 拿到调用栈后，以下是几种最常见的堆外内存泄漏模式，可供对照排查：

1. Java Netty 导致的 DirectByteBuffer 泄漏

内核/C 栈特征：
```
Unsafe_AllocateMemory+0x80 [libjvm.so]
```
Java 栈特征：
java.nio.ByteBuffer.allocateDirect 或 io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer。
排查思路：检查是否开启了 Netty 的内存池但未正确调用 ReferenceCountUtil.release() 释放 ByteBuf。

2. Gzip / ZipInflater 泄漏

内核/C 栈特征：

Java_java_util_zip_Inflater_init+0x52 [libzip.so]
allocate_ipfile_buffer [libzip.so]

排查思路：在使用 GZIPInputStream、ZipFile、Inflater 或 Deflater 时，确保在 try-finally 块中调用了 close() 或 end()。

3. Glibc Arena 内存碎片化（非真正的泄漏）

有时候，你会发现 eBPF 捕获到大量的 malloc 来自于多线程环境，且没有 Java 栈源头，而是直接由 pthread 触发。

现象：pmap -x <PID> 看到大量 64MB 的内存映射区（Arena）。
原因：Glibc 为了减少多线程竞争，会为每个线程分配独立的 Arena。在 Java 线程频繁创建和销毁时，会导致严重的内存碎片。
解决办法：在 Java 启动环境变量中设置 export MALLOC_ARENA_MAX=4，限制虚拟内存无节制增长。

六、总结与最佳实践

eBPF 为我们提供了一种非侵入、上帝视角的诊断方式。在面对 Java 堆外内存泄漏时，推荐的排查标准流水线如下：

常态化预防：生产环境 JVM 参数务必默认加上 -XX:+PreserveFramePointer。
第一步（初步诊断）：通过 jcmd <PID> VM.native_memory baseline / detail 进行 Native Memory Tracking (NMT)，确认是否是 JVM 内部组件（如 GC、Thread、Metaspace）导致的泄露。
第二步（eBPF 定位）：如果 NMT 显示 Internal 或 Unknown 字段异常增长，立即上 eBPF 链条：
- 先用 bpftrace 脚本轻量级扫描 mmap 系统调用，看是否能抓住大头。
- 若无果，生成 perf map，使用 BCC 的 memleak 挂载 malloc / mmap 进行深度还原。
第三步（修复验证）：根据还原出来的 Java 类名与 native 函数名，精准定位业务代码，进行资源释放修复。

内核性能观测者 Java eBPF 内存泄漏排查

Java 堆外内存泄漏排查：利用 eBPF (BCC) 追踪内核级与用户态分配调用栈

一、 核心痛点：为什么排查 Java 堆外内存这么难？

二、 前置准备工作