1 編寫背景
最近服務器發現tomcat的應用會偶爾出現無法訪問的情況。經過一段時間的觀察最近又發現有台tomcat的應用出現了無法訪問情況。
簡單描述下該台tomcat當時具體的表現：客戶端請求沒有響應，查看服務器端tomcat的進程是存活的，查看業務日志的時候發現日志停止沒有任何最新的訪問日志。
連tomcat下面的catalina.log也沒有任何訪問記錄，基本斷定該台tomcat已不能提供服務。
2 分析步驟
根據前面我描述的假死現象，我最先想到的是網絡是否出現了問題，是不是有什么丟包嚴重的情況，於是我開始從請求的數據流程開始分析，由於我們業務的架構采用的是nginx+tomcat的集群配置，一個請求上來的流向可以用下圖來簡單的描述一下：
- 1 - 檢查nginx的網絡情況
更改nginx的配置，讓該台nginx請求只轉到本機器的出現問題的tomcat應用上面，在access.log里看是否有網絡請求，結果可以查看到當前所有的網絡請求，也就是說可以排除是網絡的問題。
- 2 - 檢查tomcat 的網絡情況
分析業務配置的tomcat訪問日志xxxx.log上是否有日志訪問記錄，經過查詢該台tomcat應用日志完全沒有任何訪問記錄，由於我們的部署是本機的nginx轉到本機的tomcat應用，所以可以排除不是網絡問題。
到此基本可以斷定網絡沒有問題，tomcat 本身出現了假死的情況。在tomcat的日志里有報過OutOfMemoryError的異常，所以可以肯定tomcat假死的原因是OOM
3 分析JVM內存溢出
- 1.1 - 為什么會發生內存泄漏
在我們學習Java的時候就知道它最為方便的地方就是我們不需要管理內存的分配和釋放，一切由JVM自己來進行處理，當Java對象不再被應用時，等到堆內存不夠用時JVM會進行GC處理，
清除這些對象占用的堆內存空間，但是如果對象一直被應用，那么JVM是無法對其進行GC處理的，那么我們創建新的對象時，JVM就沒有辦法從堆中獲取足夠的內存分配給此對象，這時就會導致OOM。
我們出現OOM原因，一般都是因為我們不斷的往容器里存放對象，然而容器沒有相應的大小限制或清除機制，這樣就容易導致OOM。
- 1.2 - 快速定位問題
當我們的應用服務器占用了過多內存的時候，我們怎么樣才能快速的定位問題呢？要想快速定位問題，首先我們必需獲取服務器JVM某時刻的內存快照。
Jdk里面提供了很多相應的命令比如：jstack,jstat,jmap,jps等等. 在出現問題后我們應該快速保留現場。
- 2.1 - jstack
可以觀察到jvm中當前所有線程的運行情況和線程當前狀態.
sudo jstack -F 進程ID
輸出內容如下：
從上面的圖我們可以看到tomcat進程里面沒有死鎖的情況，而且每個線程都處理等待的狀態。這個時候我們可以telnet命令連上tomcat的端口查看tomcat進程是否有任務回應。
這時發現tomcat沒有任何回應可以證明tomcat應用已沒有響應處理假死狀態。
在thread dump中，要留意下面幾種狀態
死鎖，Deadlock（重點關注）
等待資源，Waiting on condition（重點關注）
• 等待獲取監視器，Waiting on monitor entry（重點關注）
阻塞，Blocked（重點關注）
• 執行中，Runnable
• 暫停，Suspended
• 對象等待中，Object.wait() 或 TIMED_WAITING
• 停止，Parked
- 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 時間過長，導致應用暫停.
- 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的數據結構所以占用比較高的內存是正常情況。
- 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
============================================
解決辦法
1) 調高web服務器的最大連接線程數，即打開tomcat的server.xml文件，設置 Connector的以下參數：minProcessors="70" maxProcessors="2000" acceptCount="2000"
2) 修改運行web服務器的機器的操作系統網絡配置，即在注冊表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters中增加以下兩個DWORD參數：
tob_id_3433
MaxUserPort＝fffe TcpTimedWaitDelay=1e 最后，重新啟動計算機。