開源產品迭代快，但也容易存在隱患。有時會遇到意料之外的問題，需要研究程式碼解決。記憶體洩漏是一個很常見的問題，會導致服務不穩定，影響可用性。本文講述瞭如何使用MAT和BTrace解決apache kylin記憶體洩漏問題，重點闡明如何定位問題，分析原因，驗證猜想。

希望能拋磚引玉，讓大家遇到類似記憶體洩漏問題時能夠有所借鑑。

## 背景

公司自助報表業務從kylin2.0叢集遷移到Kylin3.0叢集時，Kylin job角色每隔2，3天所有程式OOM一遍，服務很不穩定，需要儘快解決。

## 調查思路

構建服務是32GB堆記憶體的java程式，OOM要麼是記憶體確實不夠用，要麼是記憶體洩漏。考慮到報表業務之前使用的kylin2.0也是32GB記憶體，沒遇到類似的OOM，所以首先懷疑記憶體洩漏，可能是2.0以後的新特性引入了問題。

再考慮到kylin3.0小叢集用了很久也沒有OOM，懷疑跟業務量和用法有關係。報表業務每天要構建幾千次，構建模型各異，容易暴露出問題。一般來說，容器，Netty，ThreadLocal是記憶體洩漏的重災區。要調查記憶體洩漏，可以使用記憶體分析工具MAT來分析堆記憶體。找到哪些物件記憶體用的多，以及物件的引用關係。找到懷疑的物件後，再做進一步的程式碼分析，用BTrace列印呼叫日誌確定問題的原因，最後解決問題。

## 定位問題

java啟動引數一般都會加-XX:+HeapDumpOnOutOfMemoryError，OOM時可以dump堆記憶體,生成java_pidxxxx.hprof檔案供我們分析。

可以使用MAT(Memory Analyzer Tool)分析hprof檔案。MAT的使用可自行谷歌,有需要可以給我留言。要注意的是要堆記憶體有幾十GB，需要幾十GB的空閒記憶體做分析。一般把MAT部署在記憶體空閒的測試伺服器上，用vncserver提供視覺化操作支援。

複製hprof檔案到MAT伺服器，啟動MAT，載入hprof檔案。

載入時如果報錯

```text
An internal error occurred during: 
"Parsing heap dump from **\java_pid6564.hprof'".Java heap space
```

需要增加MAT的啟動記憶體，至少比hprof檔案大

```text
open the MemoryAnalyzer.ini file
change the default -Xmx1024m to a larger size
```

MAT分析結果

![img](https://pic1.zhimg.com/80/v2-f720d0828e41a81c085d2374a604d9b8_1440w.jpg)

![img](https://pic2.zhimg.com/80/v2-7d9cdd18326f9b6ea76120c57f830a67_1440w.jpg)

![img](https://pic1.zhimg.com/80/v2-749e5a98aaea58a5e09c84844e26ef7d_1440w.jpg)

上圖可以看出，佔用記憶體較多的物件是排程執行緒或其他執行緒的執行緒物件，每個執行緒物件佔用了較大記憶體。每次dump，執行緒物件大小不一，從200MB到1GB都有。但同一次dump，每個執行緒物件的大小几乎是一樣的。執行緒中主要是InternalThreadLocalMap物件佔用了記憶體，其中成員變數Object[]陣列的length有幾千萬甚至上億，並且每個執行緒的陣列長度都是一樣。這十有八九是記憶體洩漏。

那麼InternalThreadLocalMap是什麼物件呢？

## 分析原因

git blame，發現InternalThreadLocalMap 是KYLIN-3716 引入的，從jira看是借鑑了netty的相關程式碼，將ThreadLocal的引用替換為InternalThreadLocal（netty叫FastThreadLocal），從而讓查詢請求內部載入上下文的速度更快。那麼加快的原理又是什麼？

ThreadLocal線上程內部用map維護了執行緒內各個本地物件的引用，使用時透過查map定位到具體的物件。

而InternalThreadLocal線上程內部維護了本地物件陣列，使用時查陣列。對java來說，用陣列索引查物件要比查map快。從實現來看，每次構建InternalThreadLocal物件，Ojbect[]的的有效索引位會加1，來快取本地執行緒內對應的物件引用。但索引位只有加沒有減，如果InternalThreadLocal物件構建的特別多，Object[]的length就會很大，就會有記憶體問題。

一般來說，ThreadLocal物件都是當做靜態成員變數使用的，一個程式有幾十個物件就很多了，替換成InternalThreadLocal，陣列也不會很大，不會有問題。但如果不加控制，當成普通的成員變數來用，就會有記憶體洩漏的風險。

梳理了一下kylin專案的引用，發現大多數引用都是靜態成員變數，但有幾個類比如DataTypeSerializer，其成員變數也使用了InternalThreadLocal，這就有可能會記憶體洩漏。理論上將用在物件成員變數上的引用改回ThreadLocal問題就解決了，但穩妥起見，還是應該先驗證一下我們的猜想是否正確。

## 驗證猜想

使用BTrace來驗證我們的猜想。BTrace指令碼可以加攔截程式碼，列印方法呼叫的上下文。把BTrace指令碼掛到JVM上，不用改變線上程式碼，不用重啟，就可以輸出我們想要的日誌，是定位線上問題的神器。如何使用可自行谷歌,有需要可以給我留言。

透過BTrace指令碼的日誌，可以看到構建服務確實會頻繁構建InternalThreadLocal物件，主要是DataTypeSerializer物件初始化時呼叫的。幾個小時內InternalThreadLocal構建次數就達到了幾十上百萬。而查詢服務就沒有頻繁構建的問題，猜想被驗證正確。

## 最佳化結果

將物件成員變數的InternalThreadLocal引用改回ThreadLocal，重啟服務。InternalThreadLocal物件執行幾天也只有十幾次構建，不隨時間增多，沒再出現OOM，問題解決。相關pr已貢獻給kylin社群。

###作者：初曉【滴滴出行資深軟體開發工程師】
- [	現在註冊滴滴雲，得8888元立減紅包](https://app.didiyun.com/#/auth/signup?channel=14816)
- [7月特惠，1C2G1M雲伺服器 9.9元/月限時搶](https://www.didiyun.com/?channel=14816)
- [滴滴雲使者專屬特惠，包年雲伺服器低至68元/年](https://www.didiyun.com/envoy/e-index.html?channel=14816)
- [輸入大師碼【7886】，GPU全線產品9折優惠](https://www.didiyun.com/production/gpu.html?channel=14816)

解決記憶體洩漏(1)-ApacheKylin InternalThreadLocalMap洩漏問題分析

相關文章