07.09 一次Java線上問題排查,不得不引發的思考

一次Java線上問題排查,不得不引發的思考

鎮樓小姐姐

36份一線互聯網Java面試電子書

84個Java稀缺面試題視頻

作者:crossoverJie's Blog

前言

之前或多或少分享過一些 內存模型 、 對象創建 之類的內容,其實大部分人看完都是懵懵懂懂,也不知道這些的實際意義。

直到有一天你會碰到線上奇奇怪怪的問題,如:

  • 線程執行一個任務遲遲沒有返回,應用假死。
  • 接口響應緩慢,甚至請求超時。
  • CPU 高負載運行。

這類問題並不像一個空指針、數組越界這樣明顯好查,這時就需要剛才提到的內存模型、對象創建、線程等相關知識結合在一起來排查問題了。

正好這次藉助之前的一次生產問題來聊聊如何排查和解決問題。

生產現象

首先看看問題的背景吧:

我這其實是一個定時任務,在固定的時間會開啟 N 個線程併發的從 Redis 中獲取數據進行運算。

業務邏輯非常簡單,但應用一般涉及到多線程之後再簡單的事情都要小心對待。

果不其然這次就出問題了。

現象:原本只需要執行幾分鐘的任務執行了幾個小時都沒退出。翻遍了所有的日誌都沒找到異常。

於是便開始定位問題之路。

定位問題

既然沒辦法直接從日誌中發現異常,那就只能看看應用到底在幹嘛了。

最常見的工具就是 JDK 自帶的那一套。

這次我使用了 jstack 來查看線程的執行情況,它的作用其實就是 dump 當前的線程堆棧。

當然在 dump 之前是需要知道我應用的 pid 的,可以使用 jps -v 這樣的方式列出所有的 Java 進程。

當然如果知道關鍵字的話直接使用 ps aux|grep java 也是可以的。

拿到 pid=1523 了之後就可以利用 jstack 1523 > 1523.log 這樣的方式將 dump 文件輸出到日誌文件中。

如果應用簡單不復雜,線程這些也比較少其實可以直接打開查看。

但複雜的應用導出來的日誌文件也比較大還是建議用專業的分析工具。

我這裡的日誌比較少直接打開就可以了。

因為我清楚知道應用中開啟的線程名稱,所以直接根據線程名就可以在日誌中找到相關的堆棧:

一次Java線上問題排查,不得不引發的思考

所以通常建議大家線程名字給的有意義,在排查問題時很有必要。

其實其他幾個線程都和這裡的堆棧類似,很明顯的看出都是在做 Redis 連接。

於是我登錄 Redis 查看了當前的連接數,發現已經非常高了。

這樣 Redis 的響應自然也就變慢了。

接著利用 jps -v 列出了當前所以在跑的 Java 進程,果不其然有好幾個應用都在查詢 Redis,而且都是併發連接,問題自然就找到了。

解決辦法

所以問題的主要原因是:大量的應用併發查詢 Redis,導致 Redis 的性能降低。

既然找到了問題,那如何解決呢?

  • 減少同時查詢 Redis 的應用,分開時段降低 Redis 的壓力。
  • 將 Redis 複製幾個集群,各個應用分開查詢。但是這樣會涉及到數據的同步等運維操作,或者由程序了進行同步也會增加複雜度。

目前我們選擇的是第一個方案,效果很明顯。

本地模擬

上文介紹的是線程相關問題,現在來分析下內存的問題。

以這個類為例:

https://github.com/crossoverJie/Java-Interview/blob/master/src/main/java/com/crossoverjie/oom/heap/HeapOOM.java

public class HeapOOM {

public static void main(String[] args) {

List list = new ArrayList(10) ;

while (true){

list.add("1") ;

}

}

}

啟動參數如下:

-Xms20m

-Xmx20m

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/Users/xx/Documents

為了更快的突出內存問題將堆的最大內存固定在 20M,同時在 JVM 出現 OOM 的時候自動 dump 內存到 /Users/xx/Documents (不配路徑則會生成在當前目錄)。

執行之後果不其然出現了異常:

一次Java線上問題排查,不得不引發的思考

同時對應的內存 dump 文件也生成了。

內存分析

這時就需要相應的工具進行分析了,最常用的自然就是 MAT 了。

我試了一個在線工具也不錯(文件大了就不適合了):

http://heaphero.io/index.jsp

上傳剛才生成的內存文件之後:

一次Java線上問題排查,不得不引發的思考

因為是內存溢出,所以主要觀察下大對象:

一次Java線上問題排查,不得不引發的思考

也有相應提示,這個很有可能就是內存溢出的對象,點進去之後:

一次Java線上問題排查,不得不引發的思考

作者:crossoverJie's Blog

看到這個堆棧其實就很明顯了:

在向 ArrayList 中不停的寫入數據時,會導致頻繁的擴容也就是數組複製這些過程,最終達到 20M 的上限導致內存溢出了。

更多建議

上文說過,一旦使用了多線程,那就要格外小心。

以下是一些日常建議:

CAS+自旋

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp

總結

線上問題定位需要綜合技能,所以是需要一些基礎技能。如線程、內存模型、Linux 等。

當然這些問題沒有實操過都是紙上談兵;如果第一次碰到線上問題,不要慌張,反而應該慶幸解決之後你又會習得一項技能。


分享到:


相關文章: