背景
為了更好地實現(xiàn)對項目的管理哪轿，我們將組內一個項目遷移到MDP框架（基于Spring Boot）蹂午，隨后我們就發(fā)現(xiàn)系統(tǒng)會頻繁報出Swap區(qū)域使用量過高的異常坡垫。筆者被叫去幫忙查看原因，發(fā)現(xiàn)配置了4G堆內內存画侣，但是實際使用的物理內存竟然高達7G冰悠，確實不正常。JVM參數(shù)配置是“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m, -Xss512k -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”配乱，實際使用的物理內存如下圖所示：
top命令顯示的內存情況
排查過程
1. 使用Java層面的工具定位內存區(qū)域（堆內內存溉卓、Code區(qū)域或者使用unsafe.allocateMemory和DirectByteBuffer申請的堆外內存）
筆者在項目中添加-XX:NativeMemoryTracking=detailJVM參數(shù)重啟項目皮迟，使用命令jcmd pid VM.native_memory detail查看到的內存分布如下：
jcmd顯示的內存情況
發(fā)現(xiàn)命令顯示的committed的內存小于物理內存，因為jcmd命令顯示的內存包含堆內內存桑寨、Code區(qū)域伏尼、通過unsafe.allocateMemory和DirectByteBuffer申請的內存，但是不包含其他Native Code（C代碼）申請的堆外內存尉尾。所以猜測是使用Native Code申請內存所導致的問題爆阶。
為了防止誤判，筆者使用了pmap查看內存分布沙咏，發(fā)現(xiàn)大量的64M的地址辨图；而這些地址空間不在jcmd命令所給出的地址空間里面，基本上就斷定就是這些64M的內存所導致肢藐。
pmap顯示的內存情況
2. 使用系統(tǒng)層面的工具定位堆外內存
因為筆者已經基本上確定是Native Code所引起故河，而Java層面的工具不便于排查此類問題，只能使用系統(tǒng)層面的工具去定位問題吆豹。
首先鱼的，使用了gperftools去定位問題
gperftools的使用方法可以參考gperftools，gperftools的監(jiān)控如下：
gperftools監(jiān)控
從上圖可以看出：使用malloc申請的的內存最高到3G之后就釋放了痘煤，之后始終維持在700M-800M凑阶。筆者第一反應是：難道Native Code中沒有使用malloc申請，直接使用mmap/brk申請的衷快？（gperftools原理就使用動態(tài)鏈接的方式替換了操作系統(tǒng)默認的內存分配器（glibc）晌砾。）
然后，使用strace去追蹤系統(tǒng)調用
因為使用gperftools沒有追蹤到這些內存烦磁，于是直接使用命令“strace -f -e”brk,mmap,munmap” -p pid”追蹤向OS申請內存請求养匈，但是并沒有發(fā)現(xiàn)有可疑內存申請。strace監(jiān)控如下圖所示:
strace監(jiān)控
接著都伪，使用GDB去dump可疑內存
因為使用strace沒有追蹤到可疑內存申請呕乎；于是想著看看內存中的情況。就是直接使用命令gdp -pid pid進入GDB之后陨晶，然后使用命令dump memory mem.bin startAddress endAddressdump內存猬仁，其中startAddress和endAddress可以從/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的內容先誉，如下：
gperftools監(jiān)控
從內容上來看湿刽，像是解壓后的JAR包信息。讀取JAR包信息應該是在項目啟動的時候褐耳，那么在項目啟動之后使用strace作用就不是很大了诈闺。所以應該在項目啟動的時候使用strace，而不是啟動完成之后铃芦。
再次雅镊，項目啟動時使用strace去追蹤系統(tǒng)調用
項目啟動使用strace追蹤系統(tǒng)調用襟雷，發(fā)現(xiàn)確實申請了很多64M的內存空間，截圖如下：
strace監(jiān)控
使用該mmap申請的地址空間在pmap對應如下：
strace申請內容對應的pmap地址空間
最后仁烹，使用jstack去查看對應的線程
因為strace命令中已經顯示申請內存的線程ID耸弄。直接使用命令jstack pid去查看線程棧，找到對應的線程棧（注意10進制和16進制轉換）如下：
strace申請空間的線程棧
這里基本上就可以看出問題來了：MCC（美團統(tǒng)一配置中心）使用了Reflections進行掃包卓缰，底層使用了Spring Boot去加載JAR计呈。因為解壓JAR使用Inflater類，需要用到堆外內存征唬，然后使用Btrace去追蹤這個類捌显，棧如下：
btrace追蹤棧
然后查看使用MCC的地方，發(fā)現(xiàn)沒有配置掃包路徑鳍鸵，默認是掃描所有的包苇瓣。于是修改代碼尉间，配置掃包路徑偿乖，發(fā)布上線后內存問題解決。
3. 為什么堆外內存沒有釋放掉呢哲嘲？
雖然問題已經解決了贪薪，但是有幾個疑問：
- 為什么使用舊的框架沒有問題？
- 為什么堆外內存沒有釋放眠副？
- 為什么內存大小都是64M画切，JAR大小不可能這么大，而且都是一樣大囱怕？
- 為什么gperftools最終顯示使用的的內存大小是700M左右霍弹，解壓包真的沒有使用malloc申請內存嗎？
帶著疑問娃弓，筆者直接看了一下Spring Boot Loader那一塊的源碼典格。發(fā)現(xiàn)Spring Boot對Java JDK的InflaterInputStream進行了包裝并且使用了Inflater，而Inflater本身用于解壓JAR包的需要用到堆外內存台丛。而包裝之后的類ZipInflaterInputStream沒有釋放Inflater持有的堆外內存耍缴。于是筆者以為找到了原因，立馬向Spring Boot社區(qū)反饋了這個bug挽霉。但是反饋之后防嗡，筆者就發(fā)現(xiàn)Inflater這個對象本身實現(xiàn)了finalize方法，在這個方法中有調用釋放堆外內存的邏輯侠坎。也就是說Spring Boot依賴于GC釋放堆外內存蚁趁。
筆者使用jmap查看堆內對象時，發(fā)現(xiàn)已經基本上沒有Inflater這個對象了实胸。于是就懷疑GC的時候荣德，沒有調用finalize闷煤。帶著這樣的懷疑，筆者把Inflater進行包裝在Spring Boot Loader里面替換成自己包裝的Inflater涮瞻，在finalize進行打點監(jiān)控鲤拿，結果finalize方法確實被調用了。于是筆者又去看了Inflater對應的C代碼署咽，發(fā)現(xiàn)初始化的使用了malloc申請內存近顷，end的時候也調用了free去釋放內存。
此刻宁否，筆者只能懷疑free的時候沒有真正釋放內存窒升，便把Spring Boot包裝的InflaterInputStream替換成Java JDK自帶的，發(fā)現(xiàn)替換之后慕匠，內存問題也得以解決了饱须。
這時，再返過來看gperftools的內存分布情況台谊，發(fā)現(xiàn)使用Spring Boot時蓉媳，內存使用一直在增加，突然某個點內存使用下降了好多（使用量直接由3G降為700M左右）锅铅。這個點應該就是GC引起的酪呻，內存應該釋放了，但是在操作系統(tǒng)層面并沒有看到內存變化盐须，那是不是沒有釋放到操作系統(tǒng)玩荠，被內存分配器持有了呢？
繼續(xù)探究贼邓，發(fā)現(xiàn)系統(tǒng)默認的內存分配器（glibc 2.12版本）和使用gperftools內存地址分布差別很明顯阶冈，2.5G地址使用smaps發(fā)現(xiàn)它是屬于Native Stack。內存地址分布如下：
gperftools顯示的內存地址分布
到此塑径，基本上可以確定是內存分配器在搗鬼女坑；搜索了一下glibc 64M，發(fā)現(xiàn)glibc從2.11開始對每個線程引入內存池（64位機器大小就是64M內存）晓勇，原文如下：
glib內存池說明
按照文中所說去修改MALLOC_ARENA_MAX環(huán)境變量堂飞，發(fā)現(xiàn)沒什么效果。查看tcmalloc（gperftools使用的內存分配器）也使用了內存池方式绑咱。
為了驗證是內存池搞的鬼绰筛，筆者就簡單寫個不帶內存池的內存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成動態(tài)庫描融，然后使用export LD_PRELOAD=zjbmalloc.so替換掉glibc的內存分配器铝噩。其中代碼Demo如下：
#include<sys/mman.h>
#include<stdlib.h>
#include<string.h>
#include<stdio.h>
//作者使用的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));
}
通過在自定義分配器當中埋點可以發(fā)現(xiàn)其實程序啟動之后應用實際申請的堆外內存始終在700M-800M之間触徐，gperftools監(jiān)控顯示內存使用量也是在700M-800M左右。但是從操作系統(tǒng)角度來看進程占用的內存差別很大（這里只是監(jiān)控堆外內存）。
筆者做了一下測試川背，使用不同分配器進行不同程度的掃包砂轻，占用的內存如下：
內存測試對比
為什么自定義的malloc申請800M猫十，最終占用的物理內存在1.7G呢蚓再？
因為自定義內存分配器采用的是mmap分配內存，mmap分配內存按需向上取整到整數(shù)個頁一姿，所以存在著巨大的空間浪費七咧。通過監(jiān)控發(fā)現(xiàn)最終申請的頁面數(shù)目在536k個左右，那實際上向系統(tǒng)申請的內存等于512k * 4k（pagesize） = 2G叮叹。 為什么這個數(shù)據(jù)大于1.7G呢艾栋？
因為操作系統(tǒng)采取的是延遲分配的方式，通過mmap向系統(tǒng)申請內存的時候蛉顽，系統(tǒng)僅僅返回內存地址并沒有分配真實的物理內存蝗砾。只有在真正使用的時候，系統(tǒng)產生一個缺頁中斷携冤，然后再分配實際的物理Page悼粮。
總結
流程圖
整個內存分配的流程如上圖所示。MCC掃包的默認配置是掃描所有的JAR包噪叙。在掃描包的時候矮锈，Spring Boot不會主動去釋放堆外內存霉翔，導致在掃描階段睁蕾，堆外內存占用量一直持續(xù)飆升。當發(fā)生GC的時候债朵，Spring Boot依賴于finalize機制去釋放了堆外內存子眶；但是glibc為了性能考慮，并沒有真正把內存歸返到操作系統(tǒng)序芦，而是留下來放入內存池了臭杰，導致應用層以為發(fā)生了“內存泄漏”。所以修改MCC的配置路徑為特定的JAR包谚中，問題解決渴杆。筆者在發(fā)表這篇文章時，發(fā)現(xiàn)Spring Boot的最新版本（2.0.5.RELEASE）已經做了修改宪塔，在ZipInflaterInputStream主動釋放了堆外內存不再依賴GC磁奖；所以Spring Boot升級到最新版本，這個問題也可以得到解決某筐。
參考資料
作者簡介
- 紀兵比搭，2015年加入美團，目前主要從事酒店C端相關的工作南誊。
轉載：https://tech.meituan.com/2019/01/03/spring-boot-native-memory-leak.html
