转载：Spring Boot引起的“堆外内存泄漏”排查及经验总结

发现一篇排查sprintboot内存泄漏的文章，发现作者分析很到位，这里转载学习一下。

 

Native Memory Tracking (NMT)

首先，我们先了解一下Native Memory Tracking (NMT)。

Native Memory Tracking (NMT) 是Hotspot VM用来分析VM内部内存使用情况的一个功能。我们可以利用jcmd（jdk自带）这个工具来访问NMT的数据。

NMT介绍

工欲善其事必先利其器，我们先把相关需要的配置和工具介绍清楚，再通过例子来看看具体如何使用NMT。

打开NMT

NMT必须先通过VM启动参数中打开，不过要注意的是，打开NMT会带来5%-10%的性能损耗。

-XX:NativeMemoryTracking=[off | summary | detail]
# off: 默认关闭
# summary: 只统计各个分类的内存使用情况.
# detail: Collect memory usage by individual call sites.

jcmd查看NMT报告

通过jcmd查看NMT报告以及查看对比情况。

jcmd  VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown] [scale= KB | MB | GB]

# summary: 分类内存使用情况.
# detail: 详细内存使用情况，除了summary信息之外还包含了虚拟内存使用情况。
# baseline: 创建内存使用快照，方便和后面做对比
# summary.diff: 和上一次baseline的summary对比
# detail.diff: 和上一次baseline的detail对比
# shutdown: 关闭NMT

VM退出时打印NMT

可以通过下面VM参数在JVM退出时打印NMT报告。

-XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics

NMT实战

症状

某个服务（C）在客户环境使用后发现其内存占用不断变大且远超Xmx指定的大小，导致整个系统因缺少内存造成其他服务无法启动。当时查看到其RSS大约为11G，-Xmx=6G而且heap利用率不到50%。

user@hostxxx> prstat -p 2780
PID USERNAME  SIZE   RSS   STATE  PRI   NICE  TIME     CPU   PROCESS/NLWP
2780 user    11G     11G   sleep   59    0    44:16:39 0.0%  java/196

user@hostxxx> /opt/jdk1.8.0_40/bin/jstat -gcutil 2780
S0     S1     E      O      M     CCS    YGC     YGCT       FGC    FGCT     GCT
0.00 100.00  90.60  46.80  98.02  97.10  11323   4049.745   11     225.345   4275.090

分析

服务通过-Xmx=6G指定最大堆分配为6G，但实际RSS已达到11G，开始怀疑堆外内存是否有内存泄露。为了有更好详细的数据，就在本地重现这个问题，并且打开了NMT持续监控。

NMT的Report如下，重点关注每个分类下的commit大小，这个是实际使用的内存大小。

6739: #进程ID

Native Memory Tracking:

Total: reserved=8491110KB, committed=7220750KB
-                 Java Heap (reserved=6293504KB, committed=6291456KB) 
                            (mmap: reserved=6293504KB, committed=6291456KB) 
 
-                     Class (reserved=1107429KB, committed=66189KB) 
                            (classes #11979)
                            (malloc=1509KB #18708) 
                            (mmap: reserved=1105920KB, committed=64680KB) 
 
-                    Thread (reserved=159383KB, committed=159383KB) 
                            (thread #156)
                            (stack: reserved=158720KB, committed=158720KB)
                            (malloc=482KB #788) 
                            (arena=182KB #310)
 
-                      Code (reserved=255862KB, committed=41078KB) 
                            (malloc=6262KB #9319) 
                            (mmap: reserved=249600KB, committed=34816KB) 
 
-                        GC (reserved=449225KB, committed=449225KB) 
                            (malloc=166601KB #1714646) 
                            (mmap: reserved=282624KB, committed=282624KB) 
 
-                  Compiler (reserved=395KB, committed=395KB) 
                            (malloc=265KB #856) 
                            (arena=131KB #3)
 
-                  Internal (reserved=146041KB, committed=146041KB) 
                            (malloc=132185KB #276370) 
                            (mmap: reserved=13856KB, committed=13856KB) 
 
-                    Symbol (reserved=31487KB, committed=31487KB) 
                            (malloc=29209KB #91080) 
                            (arena=2278KB #1)
 
-    Native Memory Tracking (reserved=33212KB, committed=33212KB) 
                            (malloc=168KB #2575) 
                            (tracking overhead=33044KB)
 
-               Arena Chunk (reserved=2284KB, committed=2284KB)
                            (malloc=2284KB) 
 
-                   Unknown (reserved=12288KB, committed=0KB)
                            (mmap: reserved=12288KB, committed=0KB) 
 
Virtual memory map:
......

并且在服务器上通过cron job来定期抓取NMT的report保存下来做分析，而且同时也把其对应的RSS和PMAP都抓取了一份。

COLLECTOR_PID=`ps -ef|grep "ProcessName" | grep -v grep | awk '{print $2}'`
OUTDIR=/opt/chkmem
HOSTNAME=`hostname`

prstat -s rss 1 1 > ${OUTDIR}/${HOSTNAME}_coll_${COLLECTOR_PID}_prstat_`date '+%Y%m%d_%H%M%S'`.txt

/opt/jdk1.8.0_40/bin/jcmd ${COLLECTOR_PID} VM.native_memory detail > ${OUTDIR}/${HOSTNAME}_coll_${COLLECTOR_PID}_nmd_`date '+%Y%m%d_%H%M%S'`.txt

pmap -x ${COLLECTOR_PID} > ${OUTDIR}/${HOSTNAME}_coll_${COLLECTOR_PID}_pmap_`date '+%Y%m%d_%H%M%S'`.txt

分析发现NMT中的Symbol域持续增大，从最开始的几十兆已经增加到了2G左右，而且整个jvm的内存使用量也在持续增加。见下图： 

验证后发现问题和JDK8的一个bug https://bugs.java.com/view_bug.do?bug_id=8180048 非常类似，测试后也证实确实如此，最后通过升级JDK解决了这个问题。具体是那个组件命中了JDK的这个bug，会在下一篇文章中详细描述。

 

其他实例

jcmd 1 VM.native_memory summary scale=MB

/ # jcmd 1 VM.native_memory summary scale=MB
1:

Native Memory Tracking:

Total: reserved=2175MB, committed=682MB
-                 Java Heap (reserved=501MB, committed=463MB)
                            (mmap: reserved=501MB, committed=463MB)

-                     Class (reserved=1070MB, committed=50MB)
                            (classes #8801)
                            (  instance classes #8204, array classes #597)
                            (malloc=2MB #24660)
                            (mmap: reserved=1068MB, committed=49MB)
                            (  Metadata:   )
                            (    reserved=44MB, committed=43MB)
                            (    used=42MB)
                            (    free=1MB)
                            (    waste=0MB =0.00%)
                            (  Class space:)
                            (    reserved=1024MB, committed=6MB)
                            (    used=5MB)
                            (    free=0MB)
                            (    waste=0MB =0.00%)

-                    Thread (reserved=228MB, committed=27MB)
                            (thread #226)
                            (stack: reserved=227MB, committed=26MB)
                            (malloc=1MB #1139)

-                      Code (reserved=243MB, committed=17MB)
                            (malloc=1MB #5509)
                            (mmap: reserved=242MB, committed=16MB)

-                        GC (reserved=23MB, committed=15MB)
                            (malloc=8MB #11446)
                            (mmap: reserved=16MB, committed=7MB)

-                  Compiler (reserved=26MB, committed=26MB)
                            (malloc=2MB #1951)
                            (arena=24MB #13)

-                  Internal (reserved=5MB, committed=5MB)
                            (malloc=3MB #9745)
                            (mmap: reserved=2MB, committed=2MB)

-                     Other (reserved=2MB, committed=2MB)
                            (malloc=2MB #202)

-                    Symbol (reserved=10MB, committed=10MB)
                            (malloc=8MB #233939)
                            (arena=3MB #1)

-    Native Memory Tracking (reserved=5MB, committed=5MB)
                            (tracking overhead=5MB)

-               Arena Chunk (reserved=63MB, committed=63MB)
                            (malloc=63MB)
复制代码

• 可以看到整个memory主要包含了Java Heap、Class、Thread、Code、GC、Compiler、Internal、Other、Symbol、Native Memory Tracking、Arena Chunk这几部分；其中reserved表示应用可用的内存大小，committed表示应用正在使用的内存大小
• Java Heap部分表示heap内存目前占用了463MB；Class部分表示已经加载的classes个数为8801，其metadata占用了50MB；Thread部分表示目前有225个线程，占用了27MB；Code部分表示JIT生成的或者缓存的instructions占用了17MB；GC部分表示目前已经占用了15MB的内存空间用于帮助GC；Code部分表示compiler生成code的时候占用了26MB；Internal部分表示命令行解析、JVMTI等占用了5MB；Other部分表示尚未归类的占用了2MB；Symbol部分表示诸如string table及constant pool等symbol占用了10MB；Native Memory Tracking部分表示该功能自身占用了5MB；Arena Chunk部分表示arena chunk占用了63MB
• 一个arena表示使用malloc分配的一个memory chunk，这些chunks可以被其他subsystems做为临时内存使用，比如pre-thread的内存分配，它的内存释放是成bulk的

小结

• java8给HotSpot VM引入了Native Memory Tracking (NMT)特性，可以用于追踪JVM的内部内存使用
• 使用-XX:NativeMemoryTracking=summary可以用于开启NMT，其中该值默认为off，可以设置summary、detail来开启；开启的话，大概会增加5%-10%的性能消耗；使用-XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics可以在jvm shutdown的时候输出整体的native memory统计；其他的可以使用jcmd pid VM.native_memory相关命令进行查看、diff、shutdown等
• 整个memory主要包含了Java Heap、Class、Thread、Code、GC、Compiler、Internal、Other、Symbol、Native Memory Tracking、Arena Chunk这几部分；其中reserved表示应用可用的内存大小，committed表示应用正在使用的内存大小

 

Spring Boot引起的“堆外内存泄漏”排查及经验总结

背景

     为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因，发现配置了4G堆内内存，但是实际使用的物理内存竟然高达7G，确实不正常。JVM参数配置是：

“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m, -Xss512k -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”，

实际使用的物理内存如下图所示：

 

排查过程

1. 使用Java层面的工具定位内存区域（堆内内存、Code区域或者使用unsafe.allocateMemory和DirectByteBuffer申请的堆外内存）

笔者在项目中添加-XX:NativeMemoryTracking=detail JVM参数重启项目，使用命令jcmd pid VM.native_memory detail查看到的内存分布如下：

 

发现命令显示的committed的内存小于物理内存，因为jcmd命令显示的内存包含堆内内存、Code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。所以猜测是使用Native Code申请内存所导致的问题。

为了防止误判，笔者使用了pmap查看内存分布，发现大量的64M的地址；而这些地址空间不在jcmd命令所给出的地址空间里面，基本上就断定就是这些64M的内存所导致。

pmap -x 15573 | sort -k 3 -n -r

 

2. 使用系统层面的工具定位堆外内存

因为笔者已经基本上确定是Native Code所引起，而Java层面的工具不便于排查此类问题，只能使用系统层面的工具去定位问题。

首先，使用了gperftools去定位问题

gperftools的使用方法可以参考gperftools，gperftools的监控如下：

 

从上图可以看出：使用malloc申请的的内存最高到3G之后就释放了，之后始终维持在700M-800M。笔者第一反应是：难道Native Code中没有使用malloc申请，直接使用mmap/brk申请的？（gperftools原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc）。）

然后，使用strace去追踪系统调用

因为使用gperftools没有追踪到这些内存，于是直接使用命令[strace -f -e"brk,mmap,munmap" -p pid]追踪向OS申请内存请求，但是并没有发现有可疑内存申请。strace监控如下图所示:

 

接着，使用GDB去dump可疑内存

因为使用strace没有追踪到可疑内存申请；于是想着看看内存中的情况。就是直接使用命令gdp -pid pid进入GDB之后，然后使用命令dump memory mem.bin startAddress endAddressdump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的内容，如下：

 

从内容上来看，像是解压后的JAR包信息。读取JAR包信息应该是在项目启动的时候，那么在项目启动之后使用strace作用就不是很大了。所以应该在项目启动的时候使用strace，而不是启动完成之后。

再次，项目启动时使用strace去追踪系统调用

项目启动使用strace追踪系统调用，发现确实申请了很多64M的内存空间，截图如下：

 

使用该mmap申请的地址空间在pmap对应如下：

 

最后，使用jstack去查看对应的线程

因为strace命令中已经显示申请内存的线程ID。直接使用命令jstack pid去查看线程栈，找到对应的线程栈（注意10进制和16进制转换）如下：

 

这里基本上就可以看出问题来了：MCC（美团统一配置中心）使用了Reflections进行扫包，底层使用了Spring Boot去加载JAR。因为解压JAR使用Inflater类，需要用到堆外内存，然后使用Btrace去追踪这个类，栈如下：

 

然后查看使用MCC的地方，发现没有配置扫包路径，默认是扫描所有的包。于是修改代码，配置扫包路径，发布上线后内存问题解决。

3. 为什么堆外内存没有释放掉呢？

虽然问题已经解决了，但是有几个疑问：

• 为什么使用旧的框架没有问题？
• 为什么堆外内存没有释放？
• 为什么内存大小都是64M，JAR大小不可能这么大，而且都是一样大？
• 为什么gperftools最终显示使用的的内存大小是700M左右，解压包真的没有使用malloc申请内存吗？

带着疑问，笔者直接看了一下Spring Boot Loader那一块的源码。发现Spring Boot对Java JDK的InflaterInputStream进行了包装并且使用了Inflater，而Inflater本身用于解压JAR包的需要用到堆外内存。而包装之后的类ZipInflaterInputStream没有释放Inflater持有的堆外内存。于是笔者以为找到了原因，立马向Spring Boot社区反馈了这个bug。但是反馈之后，笔者就发现Inflater这个对象本身实现了finalize方法，在这个方法中有调用释放堆外内存的逻辑。也就是说Spring Boot依赖于GC释放堆外内存。

笔者使用jmap查看堆内对象时，发现已经基本上没有Inflater这个对象了。于是就怀疑GC的时候，没有调用finalize。带着这样的怀疑，笔者把Inflater进行包装在Spring Boot Loader里面替换成自己包装的Inflater，在finalize进行打点监控，结果finalize方法确实被调用了。于是笔者又去看了Inflater对应的C代码，发现初始化的使用了malloc申请内存，end的时候也调用了free去释放内存。

此刻，笔者只能怀疑free的时候没有真正释放内存，便把Spring Boot包装的InflaterInputStream替换成Java JDK自带的，发现替换之后，内存问题也得以解决了。

这时，再返过来看gperftools的内存分布情况，发现使用Spring Boot时，内存使用一直在增加，突然某个点内存使用下降了好多（使用量直接由3G降为700M左右）。这个点应该就是GC引起的，内存应该释放了，但是在操作系统层面并没有看到内存变化，那是不是没有释放到操作系统，被内存分配器持有了呢？

继续探究，发现系统默认的内存分配器（glibc 2.12版本）和使用gperftools内存地址分布差别很明显，2.5G地址使用smaps发现它是属于Native Stack。内存地址分布如下：

 

到此，基本上可以确定是内存分配器在捣鬼；搜索了一下glibc 64M，发现glibc从2.11开始对每个线程引入内存池（64位机器大小就是64M内存），原文如下：

 

按照文中所说去修改MALLOC_ARENA_MAX环境变量，发现没什么效果。查看tcmalloc（gperftools使用的内存分配器）也使用了内存池方式。

为了验证是内存池搞的鬼，笔者就简单写个不带内存池的内存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成动态库，然后使用export LD_PRELOAD=zjbmalloc.so替换掉glibc的内存分配器。其中代码Demo如下：

#include
#include
#include
#include
//作者使用的64位机器，sizeof(size_t)也就是sizeof(long) 
void* malloc ( size_t size )
{
   long* ptr = mmap( 0, size + sizeof(long), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0 );
   if (ptr == MAP_FAILED) {
  	return NULL;
   }
   *ptr = size;                     // First 8 bytes contain length.
   return (void*)(&ptr[1]);        // Memory that is after length variable
}

void *calloc(size_t n, size_t size) {
 void* ptr = malloc(n * size);
 if (ptr == NULL) {
	return NULL;
 }
 memset(ptr, 0, n * size);
 return ptr;
}
void *realloc(void *ptr, size_t size)
{
 if (size == 0) {
	free(ptr);
	return NULL;
 }
 if (ptr == NULL) {
	return malloc(size);
 }
 long *plen = (long*)ptr;
 plen--;                          // Reach top of memory
 long len = *plen;
 if (size <= len) {
	return ptr;
 }
 void* rptr = malloc(size);
 if (rptr == NULL) {
	free(ptr);
	return NULL;
 }
 rptr = memcpy(rptr, ptr, len);
 free(ptr);
 return rptr;
}

void free (void* ptr )
{
   if (ptr == NULL) {
	 return;
   }
   long *plen = (long*)ptr;
   plen--;                          // Reach top of memory
   long len = *plen;               // Read length
   munmap((void*)plen, len + sizeof(long));
}
复制代码

通过在自定义分配器当中埋点可以发现其实程序启动之后应用实际申请的堆外内存始终在700M-800M之间，gperftools监控显示内存使用量也是在700M-800M左右。但是从操作系统角度来看进程占用的内存差别很大（这里只是监控堆外内存）。

笔者做了一下测试，使用不同分配器进行不同程度的扫包，占用的内存如下：

 

      为什么自定义的malloc申请800M，最终占用的物理内存在1.7G呢？

      因为自定义内存分配器采用的是mmap分配内存，mmap分配内存按需向上取整到整数个页，所以存在着巨大的空间浪费。通过监控发现最终申请的页面数目在536k个左右，那实际上向系统申请的内存等于512k * 4k（pagesize） = 2G。 为什么这个数据大于1.7G呢？

      因为操作系统采取的是延迟分配的方式，通过mmap向系统申请内存的时候，系统仅仅返回内存地址并没有分配真实的物理内存。只有在真正使用的时候，系统产生一个缺页中断，然后再分配实际的物理Page。

总结

 

      整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。笔者在发表这篇文章时，发现Spring Boot的最新版本（2.0.5.RELEASE）已经做了修改，在ZipInflaterInputStream主动释放了堆外内存不再依赖GC；所以Spring Boot升级到最新版本，这个问题也可以得到解决。

参考资料

1. GNU C Library (glibc)
2. Native Memory Tracking
3. Spring Boot
4. gperftools
5. Btrace

 

转自

https://juejin.im/post/6844903752298676238

https://juejin.im/post/6844903806468096013