1.1 編寫目的

 為了方便大家以後發現程序假死的時候能夠正常的分析並且第一時間保留現場快照。

1.2編寫背景

最近伺服器發現tomcat的應用會偶爾出現無法訪問的情況。經過一段時間的觀察最近又發現有臺tomcat的應用出現了無法訪問情況。簡單描述下該臺tomcat當時具體的表現：客戶端請求沒有響應，檢視伺服器端tomcat的程序是存活的，檢視業務日誌的時候發現日誌停止沒有任何最新的訪問日誌。連tomcat下面的catalina.log也沒有任何訪問記錄，基本斷定該臺tomcat已不能提供服務。

2 分析步驟

根據前面我描述的假死現象，我最先想到的是網路是否出現了問題，是不是有什麼丟包嚴重的情況，於是我開始從請求的資料流程開始分析，由於我們業務的架構採用的是nginx+tomcat的叢集配置，一個請求上來的流向可以用下圖來簡單的描述一下：

2.1檢查nginx的網路情況

更改nginx的配置，讓該臺nginx請求只轉到本機器的出現問題的tomcat應用上面，在access.log裡看是否有網路請求，結果可以檢視到當前所有的網路請求，也就是說可以排除是網路的問題。

2.2檢查tomcat 的網路情況

分析業務配置的tomcat訪問日誌xxxx.log上是否有日誌訪問記錄，經過查詢該臺tomcat應用日誌完全沒有任何訪問記錄，由於我們的部署是本機的nginx轉到本機的tomcat應用，所以可以排除不是網路問題。到此基本可以斷定網路沒有問題，tomcat 本身出現了假死的情況。在tomcat的日誌裡有報過OutOfMemoryError的異常，所以可以肯定tomcat假死的原因是OOM

3 分析JVM記憶體溢位

3.1為什麼會發生記憶體洩漏

在我們學習Java的時候就知道它最為方便的地方就是我們不需要管理記憶體的分配和釋放，一切由JVM自己來進行處理，當Java物件不再被應用時，等到堆記憶體不夠用時JVM會進行GC處理，清除這些物件佔用的堆記憶體空間，但是如果物件一直被應用，那麼JVM是無法對其進行GC處理的，那麼我們建立新的物件時，JVM就沒有辦法從堆中獲取足夠的記憶體分配給此物件，這時就會導致OOM。我們出現OOM原因，一般都是因為我們不斷的往容器裡存放物件，然而容器沒有相應的大小限制或清除機制，這樣就容易導致OOM。

3.2快速定位問題

    當我們的應用伺服器佔用了過多記憶體的時候，我們怎麼樣才能快速的定位問題呢？要想快速定位問題，首先我們必需獲取伺服器JVM某時刻的記憶體快照。Jdk裡面提供了很多相應的命令比如：jstack,jstat,jmap,jps等等. 在出現問題後我們應該快速保留現場。

3.2.1 jstack

可以觀察到jvm中當前所有執行緒的執行情況和執行緒當前狀態.

sudo jstack -F 程序ID
輸出內容如下：

從上面的圖我們可以看到tomcat程序裡面沒有死鎖的情況，而且每個執行緒都處理等待的狀態。這個時候我們可以telnet命令連上tomcat的埠檢視tomcat程序是否有任務迴應。這時發現tomcat沒有任何迴應可以證明tomcat應用已沒有響應處理假死狀態。

3.2.2 jstat

這是jdk命令中比較重要，也是相當實用的一個命令，可以觀察到classloader，compiler，gc相關資訊
具體引數如下：
-class：統計class loader行為資訊
-compile：統計編譯行為資訊
-gc：統計jdk gc時heap資訊
-gccapacity：統計不同的generations（包括新生區，老年區，permanent區）相應的heap容量情況
-gccause：統計gc的情況，（同-gcutil）和引起gc的事件
-gcnew：統計gc時，新生代的情況
-gcnewcapacity：統計gc時，新生代heap容量
-gcold：統計gc時，老年區的情況
-gcoldcapacity：統計gc時，老年區heap容量
-gcpermcapacity：統計gc時，permanent區heap容量
-gcutil：統計gc時，heap情況
-printcompilation：不知道幹什麼的，一直沒用過。

一般比較常用的幾個引數是：
sudo jstat -class 2083 1000 10 （每隔1秒監控一次，一共做10次）

檢視當時的head情況

sudo jstat -gcutil  20683 2000

 

注：該圖不是出錯擷取

出現時候擷取的資料是gc已經完全沒有處理了,因為沒有加上full gc的日誌所以不確定JVMGC 時間過長，導致應用暫停.

3.2.3獲取記憶體快照

Jdk自帶的jmap可以獲取內在某一時刻的快照

命令：jmap -dump:format=b,file=heap.bin <pid>
file：儲存路徑及檔名
pid：程序編號（windows通過工作管理員檢視，linux通過ps aux檢視）
dump檔案可以通過MemoryAnalyzer分析檢視，網址：http://www.eclipse.org/mat/，可以檢視dump時物件數量，記憶體佔用，執行緒情況等。

 從上面的圖可以看得出來物件沒有記憶體溢位。

從上圖我們可以明確的看出此專案的HashMap記憶體使用率比較高，因為我們的系統都是返回Map的資料結構所以佔用比較高的記憶體是正常情況。

3.2.4觀察執行中的jvm實體記憶體的佔用情況    

觀察執行中的jvm實體記憶體的佔用情況。我們也可以用jmap命令
引數如下：
-heap：列印jvm heap的情況
-histo：列印jvm heap的直方圖。其輸出資訊包括類名，物件數量，物件佔用大小。
-histo：live ：同上，但是隻答應存活物件的情況
-permstat：列印permanent generation heap情況

命令使用：
jmap -heap 2083
可以觀察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的記憶體使用情況
輸出內容：

 

上圖為tomcat應用出錯前JVM的配置資訊,可以明確的看到當時的資訊:

MaxHeapSize堆記憶體大小為：3500M

MaxNewSize新生代記憶體大小：512M

PermSize永久代記憶體大小:192M

NewRatio設定年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設定為2，則年輕代與年老代所佔比值為1：2，年輕代佔整個堆疊的1/3

SurvivorRatio設定年輕代中Eden區與Survivor區的大小比值。設定為8，則兩個Survivor區與一個Eden區的比值為2:8，一個Survivor區佔整個年輕代的1/10

在New Generation中，有一個叫Eden的空間，主要是用來存放新生的物件，還有兩個SurvivorSpaces（from,to）, 它們用來存放每次垃圾回收後存活下來的物件。在Old Generation中，主要存放應用程式中生命週期長的記憶體物件，還有個Permanent Generation，主要用來放JVM自己的反射物件，比如類物件和方法物件等。

從上面的圖可以看出來JVM的新生代設定太小，可以看出應用的新生代區完全佔滿了，無法再往新生代區增加新的物件此時的這些物件都處於活躍狀態，所以不會被GC處理，但是tomcat應用還在繼續產生新的物件，這樣就會導致OOM的發生，這就是導致tomcat假死的原因.

4 Tomcat假死其它情況

         以下是網上資料說的tomcat假的情況：

1、應用本身程式的問題，造成死鎖。

2、load 太高，已經超出服務的極限

3、jvm GC 時間過長，導致應用暫停

因為出錯專案裡面沒有打出GC的處理情況，所以不確定此原因是否也是我專案tomcat假死的原因之一。

4、大量tcp 連線 CLOSE_WAIT

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 

TIME_WAIT 48

CLOSE_WAIT 2228

ESTABLISHED 86

常用的三個狀態是：ESTABLISHED 表示正在通訊，T