1 背景

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假的情況：

• 應用本身程序的問題，造成死鎖。
• load 太高，已經超出服務的極限
• jvm GC時間過長，導致應用暫停
  • 因為出錯項目里面沒有打出GC的處理情況，所以不確定此原因是否也是我項目tomcat假死的原因之一。
• 大量tcp 連接 CLOSE_WAIT
  • netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'