揭开Java容器‘消失的内存’之谜：云监控2.0 SysOM诊断实践

背景

在前一篇文章《一次内存诊断，让资源利用率提升40%：揭秘隐式内存治理》[1]中，我们系统性地剖析了云原生环境中隐性内存开销的诊断方法，通过SysOM系统诊断实现了对节点/Pod级由文件缓存、共享内存等系统级内存资源异常消耗的精准定位。

然而，部分场景下内存异常仍可能源于应用进程本身的内存申请，但是对于应用内存泄漏问题，尽管是应用的开发者，也需要投入大量的精力去利用对应语言的内存分析工具去找出根因；以Java应用为例，当传统线下IDC集群中的Java应用完成云原生架构转型后，伴随容器化封装与资源配额管控的实施，用户普遍反馈Java应用Pod出现持续性内存超限及Kubernetes OOMKilled事件。这一系列现象主要集中在三个关键矛盾点：

容器内存监控与JVM堆内存的显著差异
Pod内存占用常超出JVM堆内存（含堆外内存）数倍，形成"消失的内存"谜团
容器化改造后的OS兼容性问题
同一业务系统在切换OS或容器化后，出现内存占用模式突变
工具链覆盖盲区
传统Java内存分析工具无法覆盖JNI内存、LIBC内存等非JVM内存区域

为此，云监控2.0[2]中的SysOM系统诊断对应用内存进一步深挖，结合应用和操作系统的角度实现对主机、容器运行时及具体的Java应用进程进行内存占用拆解，快速有效地识别出Java内存占用的元凶

Java内存全景分析

为了找出消失的内存，我们首先要了解Java进程的主要内存组成以及现有工具和监控主要覆盖的部分；如下图所示可分为：

JVM内存

- 堆内存：可通过-Xms/-Xmx参数控制，内存大小可通过memorymxbean等获取。
- 堆外内存：包括元空间、压缩类空间、代码缓冲区、直接缓冲、线程栈等内存组成；它们分别可以通过-XX:MaxMetaspaceSize（元空间）、-XX:CompressedClassSpaceSize （压缩类空间）、 -XX:ReservedCodeCacheSize（代码缓冲区）、-XX:MaxDirectMemorySize (直接缓冲)、-Xss（线程栈）参数限制。

非JVM内存：

- JNI本地内存：即通过本地方法接口调用C、C++代码（原生库），并在这部分代码中调用C库（malloc）或系统调用（brk、mmap）直接分配的内存。

Java常见“内存泄漏”

JNI内存泄漏

经过上一章中对Java内内存全景的分析，其实已经可以揭开第一个容易造成内存黑洞的隐藏Boss-JNI内存，因为这部分内存暂时没有工具可以获取其占用大小。

通常来说，编写相关业务代码的同学会认为代码中没有使用本地方法直接调用C库，所以不会存在这些问题，但是代码中引用的各种包却有可能会使用到JNI内存，比如说经典的使用ZLIB 压缩库不当导致的JNI泄漏问题[3]

LIBC内存管理特性

JVM向OS申请内存的中间，还存在着一层中间层-C库，JVM调用malloc、free申请/释放内存的过程中其实还要经过这一个二道贩子；以gibc中默认的内存分配器ptmalloc为例glibc的ptmalloc内存分配器存在以下特征：

Arena机制：每个线程维护64M Arena，多线程场景下易产生内存碎片
Top Chunk管理：内存空洞导致无法及时归还OS
Bins缓存策略：JVM释放的内存暂存于bins中，造成统计偏差[4-5]

Linux透明大页（THP）影响

在OS层，Linux中的透明大页（Transparent Huge Page）机制也是造成JVM内存和实际内存差异的一大元凶。简单来说，THP机制就是OS会将4kb页变成2M的大页，从而减少TLB miss和缺页中断，提升应用性能，但是也带来了一些内存浪费。如应用申请了一段2M的虚拟内存，但实际只用了里面的4kb，但是由于THP机制，OS已经分配了一个2M的页了[6];