Java內存泄漏實例排查分析

這篇文章主要介紹“Java內存泄漏實例排查分析”，在日常操作中，相信很多人在Java內存泄漏實例排查分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Java內存泄漏實例排查分析”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

問題出現

晚上七點多開始，我就開始不停地收到報警郵件，郵件顯示探測的幾個接口有超時情況。

多數執行棧都在：

java.io.BufferedReader.readLine(BufferedReader.java:371) java.io.BufferedReader.readLine(BufferReader.java:389) java_io_BufferedReader$readLine.call(Unknown Source) com.domain.detect.http.HttpClient.getResponse(HttpClient.groovy:122) com.domain.detect.http.HttpClient.this$2$getResponse(HttpClient.groovy)

這個線程棧的報錯我見得多了，我們設置的 HTTP DNS 超時是 1s，connect 超時是 2s，read 超時是 3s。

這種報錯都是探測服務正常發送了 HTTP  請求，服務器也在收到請求正常處理后正常響應了，但數據包在網絡層層轉發中丟失了，所以請求線程的執行棧會停留在獲取接口響應的地方。

這種情況的典型特征就是能在服務器上查找到對應的日志記錄。而且日志會顯示服務器響應完全正常。

與它相對的還有線程棧停留在 Socket connect 處的，這是在建連時就失敗了，服務端完全無感知。

我注意到其中一個接口報錯更頻繁一些，這個接口需要上傳一個 4M 的文件到服務器，然后經過一連串的業務邏輯處理，再返回 2M 的文本數據。

而其他的接口則是簡單的業務邏輯，我猜測可能是需要上傳下載的數據太多，所以超時導致丟包的概率也更大吧。

根據這個猜想，群登上服務器，使用請求的 request_id 在近期服務日志中搜索一下，果不其然，就是網絡丟包問題導致的接口超時了。

當然這樣 leader 是不會滿意的，這個結論還得有人接鍋才行。于是趕緊聯系運維和網絡組，向他們確認一下當時的網絡狀態。

網絡組同學回復說是我們探測服務所在機房的交換機老舊，存在未知的轉發瓶頸，正在優化，這讓我更放心了，于是在部門群里簡單交待一下，算是完成任務。

問題爆發

本以為這次值班就起這么一個小波浪，結果在晚上八點多，各種接口的報警郵件蜂擁而至，打得準備收拾東西過周日單休的我措手不及。

這次幾乎所有的接口都在超時，而我們那個大量網絡 I/O 的接口則是每次探測必超時，難道是整個機房故障了么?

我再次通過服務器和監控看到各個接口的指標都很正常，自己測試了下接口也完全  OK，既然不影響線上服務，我準備先通過探測服務的接口把探測任務停掉再慢慢排查。

結果給暫停探測任務的接口發請求好久也沒有響應，這時候我才知道沒這么簡單。

解決問題

內存泄漏

于是趕快登陸探測服務器，首先是 top free df 三連，結果還真發現了些異常：

我們的探測進程 CPU 占用率特別高，達到了 900%。

我們的 Java 進程，并不做大量 CPU 運算，正常情況下，CPU 應該在 100~200% 之間，出現這種 CPU  飆升的情況，要么走到了死循環，要么就是在做大量的 GC。

使用 jstat -gc pid [interval] 命令查看了 Java 進程的 GC 狀態，果然，FULL GC 達到了每秒一次：

這么多的 FULL GC，應該是內存泄漏沒跑了，于是使用 jstack pid > jstack.log 保存了線程棧的現場。

使用 jmap -dump:format=b,file=heap.log pid 保存了堆現場，然后重啟了探測服務，報警郵件終于停止了。

jstat

jstat 是一個非常強大的 JVM 監控工具，一般用法是：

jstat [-options] pid interval

它支持的查看項有：

• class 查看類加載信息。

• compile 編譯統計信息。

• gc 垃圾回收信息。

• gcXXX 各區域 GC 的詳細信息，如 -gcold。

使用它，對定位 JVM 的內存問題很有幫助。

排查問題

問題雖然解決了，但為了防止它再次發生，還是要把根源揪出來。

分析棧

棧的分析很簡單，看一下線程數是不是過多，多數棧都在干嘛：

> grep 'java.lang.Thread.State' jstack.log  | wc -l > 464

才四百多線程，并無異常：

> grep -A 1 'java.lang.Thread.State' jstack.log  | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n       10     at java.lang.Class.forName0(Native Method)      10     at java.lang.Object.wait(Native Method)      16     at java.lang.ClassLoader.loadClass(ClassLoader.java:404)      44     at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)     344     at sun.misc.Unsafe.park(Native Method)

線程狀態好像也無異常，接下來分析堆文件。

下載堆 dump 文件

堆文件都是一些二進制數據，在命令行查看非常麻煩，Java 為我們提供的工具都是可視化的，Linux  服務器上又沒法查看，那么首先要把文件下載到本地。

由于我們設置的堆內存為 4G，所以 dump 出來的堆文件也很大，下載它確實非常費事，不過我們可以先對它進行一次壓縮。

gzip 是個功能很強大的壓縮命令，特別是我們可以設置 -1~-9 來指定它的壓縮級別。

數據越大壓縮比率越大，耗時也就越長，推薦使用 -6~7，-9 實在是太慢了，且收益不大，有這個壓縮的時間，多出來的文件也下載好了。

使用 MAT 分析 jvm heap

MAT 是分析 Java 堆內存的利器，使用它打開我們的堆文件(將文件后綴改為 .hprof), 它會提示我們要分析的種類。

對于這次分析，果斷選擇 memory leak suspect：

從上面的餅圖中可以看出，絕大多數堆內存都被同一個內存占用了，再查看堆內存詳情，向上層追溯，很快就發現了罪魁禍首。

分析代碼

找到內存泄漏的對象了，在項目里全局搜索對象名，它是一個 Bean 對象，然后定位到它的一個類型為 Map 的屬性。

這個 Map 根據類型用 ArrayList 存儲了每次探測接口響應的結果，每次探測完都塞到 ArrayList 里去分析。

由于 Bean 對象不會被回收，這個屬性又沒有清除邏輯，所以在服務十來天沒有上線重啟的情況下，這個 Map 越來越大，直至將內存占滿。

內存滿了之后，無法再給 HTTP 響應結果分配內存了，所以一直卡在 readLine 那里。而我們那個大量 I/O  的接口報警次數特別多，估計跟響應太大需要更多內存有關。

給代碼 owner 提了 PR，問題圓滿解決。

到此，關于“Java內存泄漏實例排查分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！