記一次 JAVA 的記憶體洩露分析
背景
前不久，上線了一個新專案，這個專案是一個壓測系統，可以簡單的看做通過回放詞表（http請求資料），不斷地向服務傳送請求，以達到壓測服務的目的。在測試過程中，一切還算順利，修復了幾個小bug後，就上線了。在上線後給到第一個業務方使用時，就發現來一個嚴重的問題，應用大概跑了10多分鐘，就收到了大量的 Full GC 的告警。
針對這一問題，我們首先和業務方確認了壓測的場景內容，回放的詞表數量大概是10萬條，回放的速率單機在 100qps 左右，按照我們之前的預估，這遠遠低於單機能承受的極限。按道理是不會產生記憶體問題的。
線上排查
首先，我們需要在伺服器上進行排查。通過 JDK 自帶的 jmap 工具，檢視一下 JAVA 應用中具體存在了哪些物件，以及其例項數和所佔大小。具體命令如下：
jmap -histo:live `pid of java`
# 為了便於觀察，還是將輸出寫入檔案
jmap -histo:live `pid of java` > /tmp/jmap00
經過觀察，確實發現有物件被例項化了20多萬，根據業務邏輯，例項化最多的也就是詞表，那也就10多萬，怎麼會有20多萬呢，我們在程式碼中也沒有找到對此有顯示宣告例項化的地方。至此，我們需要對 dump 記憶體，在離線進行進一步分析，dump 命令如下：
jmap -dump:format=b,file=heap.dump `pid of java
離線分析
從伺服器上下載了 dump 的 heap.dump 後，我們需要通過工具進行深入的分析。這裡推薦的工具有 mat、visualVM。
我個人比較喜歡使用 visualVM 進行分析，它除了可以分析離線的 dump 檔案，還可以與 IDEA 進行整合，通過 IDEA 啟動應用，進行實時的分析應用的CPU、記憶體以及GC情況（GC情況，需要在visualVM中安裝visual GC 外掛）。工具具體展示如下（這裡僅僅為了展示效果，資料不是真的）：
當然，mat 也是非常好用的工具，它能幫我們快速的定位到記憶體洩露的地方，便於我們排查。展示如下：
場景再現
經過分析，最後我們定位到是使用 httpasyncclient 產生的記憶體洩露問題。
httpasyncclient 是 Apache 提供的一個 HTTP 的工具包，主要提供了 reactor 的 io 非阻塞模型，實現了非同步傳送 http 請求的功能。
下面通過一個 Demo，來簡單講下具體記憶體洩露的原因。
httpasyncclient 使用介紹:
1.maven 依賴
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpasyncclient</artifactId>
<version>4.1.3</version>
</dependency>
2.HttpAsyncClient 客戶端
public class HttpAsyncClient {
private CloseableHttpAsyncClient httpclient;
public HttpAsyncClient() {
httpclient = HttpAsyncClients.createDefault();
httpclient.start();
}
public void execute(HttpUriRequest request, FutureCallback<HttpResponse> callback){
httpclient.execute(request, callback);
}
public void close() throws IOException {
httpclient.close();
}
}
主要邏輯：
Demo 的主要邏輯是這樣的，首先建立一個快取列表，用來儲存需要傳送的請求資料。
然後，通過迴圈的方式從快取列表中取出需要傳送的請求，將其交由 httpasyncclient 客戶端進行傳送。
具體程式碼如下：
public class ReplayApplication {
public static void main(String[] args) throws InterruptedException {
//建立有記憶體洩露的回放客戶端
ReplayWithProblem replay1 = new ReplayWithProblem();
//載入一萬條請求資料放入快取
List<HttpUriRequest> cache1 = replay1.loadMockRequest(10000);
//開始迴圈回放
replay1.start(cache1);
}
}
回放客戶端實現（記憶體洩露）：
這裡以回放百度為例，建立10000條mock資料放入快取列表。回放時，以 while 迴圈每100ms 傳送一個請求出去。具體程式碼如下:
public class ReplayWithProblem {
public List<HttpUriRequest> loadMockRequest(int n){
List<HttpUriRequest> cache = new ArrayList<HttpUriRequest>(n);
for (int i = 0; i < n; i++) {
HttpGet request = new HttpGet("http://www.baidu.com?a="+i);
cache.add(request);
}
return cache;
}
public void start(List<HttpUriRequest> cache) throws InterruptedException {
HttpAsyncClient httpClient = new HttpAsyncClient();
int i = 0;
while (true){
final HttpUriRequest request = cache.get(i%cache.size());
httpClient.execute(request, new FutureCallback<HttpResponse>() {
public void completed(final HttpResponse response) {
System.out.println(request.getRequestLine() + "->" + response.getStatusLine());
}
public void failed(final Exception ex) {
System.out.println(request.getRequestLine() + "->" + ex);
}
public void cancelled() {
System.out.println(request.getRequestLine() + " cancelled");
}
});
i++;
Thread.sleep(100);
}
}
}
記憶體分析：
啟動 ReplayApplication 應用（IDEA 中安裝 VisualVM Launcher後，可以直接啟動visualvm），通過 visualVM 進行觀察。
1.啟動情況：
2.visualVM 中前後3分鐘的記憶體物件佔比情況：
說明：$0代表的是物件本身，$1代表的是該物件中的第一個內部類。所以ReplayWithProblem$1: 代表的是ReplayWithProblem類中FutureCallback的回撥類。
從中，我們可以發現 FutureCallback 類會被不斷的建立。因為每次非同步傳送 http 請求，都是通過建立一個回撥類來接收結果，邏輯上看上去也正常。不急，我們接著往下看。
3.visualVM 中前後3分鐘的GC情況：
從圖中看出，記憶體的 old 在不斷的增長，這就不對了。記憶體中維持的應該只有快取列表的http請求體，現在在不斷的增長，就有說明了不斷的有物件進入old區，結合上面記憶體物件的情況，說明了 FutureCallback 物件沒有被及時的回收。
可是該回調匿名類在 http 回撥結束後，引用關係就沒了，在下一次 GC 理應被回收才對。我們通過對 httpasyncclient 傳送請求的原始碼進行跟蹤了一下後發現，其內部實現是將回調類塞入到了http的請求類中，而請求類是放在在快取佇列中，所以導致回撥類的引用關係沒有解除，大量的回撥類晉升到了old區，最終導致 Full GC 產生。
核心程式碼分析：
程式碼優化
找到問題的原因，我們現在來優化程式碼，驗證我們的結論。因為List
程式碼如下：
public class ReplayApplication {
public static void main(String[] args) throws InterruptedException {
ReplayWithoutProblem replay2 = new ReplayWithoutProblem();
List<String> cache2 = replay2.loadMockRequest(10000);
replay2.start(cache2);
}
}
public class ReplayWithoutProblem {
public List<String> loadMockRequest(int n){
List<String> cache = new ArrayList<String>(n);
for (int i = 0; i < n; i++) {
cache.add("http://www.baidu.com?a="+i);
}
return cache;
}
public void start(List<String> cache) throws InterruptedException {
HttpAsyncClient httpClient = new HttpAsyncClient();
int i = 0;
while (true){
String url = cache.get(i%cache.size());
final HttpGet request = new HttpGet(url);
httpClient.execute(request, new FutureCallback<HttpResponse>() {
public void completed(final HttpResponse response) {
System.out.println(request.getRequestLine() + "->" + response.getStatusLine());
}
public void failed(final Exception ex) {
System.out.println(request.getRequestLine() + "->" + ex);
}
public void cancelled() {
System.out.println(request.getRequestLine() + " cancelled");
}
});
i++;
Thread.sleep(100);
}
}
}
結果驗證
1.啟動情況：
2.visualVM 中前後3分鐘的記憶體物件佔比情況：
3.visualVM 中前後3分鐘的GC情況：
從圖中，可以證明我們得出的結論是正確的。回撥類在 Eden 區就會被及時的回收掉。old 區也沒有持續的增長情況了。這一次的記憶體洩露問題算是解決了。
總結
關於記憶體洩露問題在第一次排查時，往往是有點不知所措的。我們需要有正確的方法和手段，配上好用的工具，這樣在解決問題時，才能遊刃有餘。當然對JAVA記憶體的基礎知識也是必不可少的，這時你定位問題的關鍵，不然就算工具告訴你這塊有錯，你也不能定位原因。
最後，關於 httpasyncclient 的使用，工具本身是沒有問題的。只是我們得了解它的使用場景，往往產生問題多的，都是使用的不當造成的。所以，在使用工具時，對於它的瞭解程度，往往決定了出現 bug 的機率。
作者：jasonGeng88
來源：https://github.com/jasonGeng88/blog
歡迎關注我的微信公眾號「碼農突圍」，分享Python、Java、大資料、機器學習、人工智慧等技術，關注碼農技術提升•職場突圍•思維躍遷，20萬+碼農成長充電第一站，陪有夢想的你一起成長