http://www.myexception.cn/open-source/921974.html

Tomcat 假死原因分析

Tomcat 假死原因分析報告

最近監控服務發現有臺tomcat 的應用出現了無法訪問的情況，由于已做了集群，基本沒有影響線上服務的正常使用。下面來簡單描述該臺tomcat當時具體的表現：客戶端請求沒有響應，查看服務器端tomcat 的java 進程存活，查看tomcat 的catalina.log ,沒有發現異常，也沒有error 日志.查看localhost_access.log 也沒有最新的訪問日志，該臺tomcat 已不能提供服務。

? ?根據前面的假死表象，最先想到的是網絡是否出現了問題，于是開始從請求的數據流程開始分析。由于業務的架構采用的是nginx + tomcat 的集群配置，一個請求上來的流向可以用下圖來簡單的描述。

從上圖可以看出，如果是網絡的原因，可以從兩個點進行分析。

? ?1、從前端到nginx的網絡情況；

分析nginx上的access.log ，在其中一臺上可以查出當時該條請求的訪問日志，也就是說可以排除這段網絡的問題。

? ?2、從nginx 到tomcat 的網絡情況。

分析tomcat 的訪問日志localhost_acess.log 上無法查出該條請求的訪問日志。可以懷疑是否網絡有問題。就該情況，從該臺nginx ping 了一下tomcat server ，均為正常，沒有發現問題。既然網絡貌似沒有問題，開始懷疑是tomcat本身的問題，在tomcat本機直接curl 調用該條請求，發現仍然沒有響應。到此基本可以斷定網絡沒有問題，tomcat 本身出現了假死的情況。

基于tomcat 假死的情況，開始分析有可能的原因。造成tomcat假死有可能的情況大概有以下幾種：

一、tomcat jvm 內存溢出

? ? ? ? ?分析當時的gc.log ?，

7581861.927: [GC 7581861.927: [ParNew
Desired survivor size 76677120 bytes, new threshold 15 (max 15)
- age ? 1: ? ?5239168 bytes, ? ?5239168 total
: 749056K->10477K(898816K), 0.0088550 secs] 1418818K->680239K(8238848K), 0.0090350 secs]

? ? 沒有發現有內存溢出的情況

? ?直接grep catalina.sh 也沒有結果，證明沒有發生內存溢出的情況 ，,這種假死可能可以排除。

? ?grep OutOfMemoryException catalina.sh

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

? ? ? 7581088.402: [Full GC (System) 7581088.402: [CMS: 661091K->669762K(7340032K), 1.7206330 secs] 848607K->669762K(8238848K), [CMS Perm : 34999K->34976K(58372K)], 1.7209480 secs] [Times: user=1.72 sys=0.00, real=1.72 secs]

? ? ?最近的一次full gc 顯示，也不應該會暫停幾分鐘的情況,這種假死可能可以排除。

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

? ? ? ? 當時top一下linux

? ? ? ? top

load average: 0.02, 0.02, 0.00
Tasks: 272 total, ? 1 running, 271 sleeping, ? 0 stopped, ? 0 zombie
Cpu(s): ?0.2%us, ?0.2%sy, ?0.0%ni, 99.6%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
Mem: ?32950500k total, 23173908k used, ?9776592k free, ?1381456k buffers
Swap: 33551744k total, ? ? ?236k used, 33551508k free, 12320412k cached

? ? ? ? load 并不是高，,這種假死可能可以排除。

四、應用本身程序的問題，造成死鎖。

? ? ? ? 針對這種情況，做了一下jstack，有少量線程處于TIMED_WAITING。

"Ice.ThreadPool.Client-75" daemon prio=10 tid=0x000000005c5ed800 nid=0x4cde in Object.wait() [0x0000000047738000]
? java.lang.Thread.State: TIMED_WAITING (on object monitor)
? ? ? ?at java.lang.Object.wait(Native Method)
? ? ? ?- waiting on <0x00002aab14336a10> (a IceInternal.ThreadPool)
? ? ? ?at IceInternal.ThreadPool.followerWait(ThreadPool.java:554)
? ? ? ?- locked <0x00002aab14336a10> (a IceInternal.ThreadPool)
? ? ? ?at IceInternal.ThreadPool.run(ThreadPool.java:344)
? ? ? ?- locked <0x00002aab14336a10> (a IceInternal.ThreadPool)
? ? ? ?at IceInternal.ThreadPool.access$300(ThreadPool.java:12)
? ? ? ?at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:643)
? ? ? ?at java.lang.Thread.run(Thread.java:619)

? ? ? ?"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=10 tid=0x00002aacc4347800 nid=0x651 waiting on condition [0x00000000435f7000]
? java.lang.Thread.State: TIMED_WAITING (sleeping)
? ? ? ?at java.lang.Thread.sleep(Native Method)
? ? ? ?at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1378)
? ? ? ?at java.lang.Thread.run(Thread.java:619)

"version sniffer" daemon prio=10 tid=0x00002aacc4377000 nid=0x645 in Object.wait() [0x0000000040f3c000]
? java.lang.Thread.State: TIMED_WAITING (on object monitor)
? ? ? ?at java.lang.Object.wait(Native Method)
? ? ? ?- waiting on <0x00002aaaee20b7b8> (a java.lang.Boolean)
? ? ? ?at com.panguso.map.web.service.LocateServiceFactory$IpDataVersionSniffer.run(LocateServiceFactory.java:351)
? ? ? ?- locked <0x00002aaaee20b7b8> (a java.lang.Boolean)
? ? ? ?at java.lang.Thread.run(Thread.java:619)

"ReplicaSetStatus:Updater" daemon prio=10 tid=0x000000005d070800 nid=0x636 waiting on condition [0x0000000044001000]
? java.lang.Thread.State: TIMED_WAITING (sleeping)
? ? ? ?at java.lang.Thread.sleep(Native Method)
? ? ? ?at com.mongodb.ReplicaSetStatus$Updater.run(ReplicaSetStatus.java:428)

? ?從jvm 堆棧信息可以看出，其中有可能出現線程鎖死的情況為：IceInternal 和訪問mongdb 的客戶端 com.mongodb.ReplicaSetStatus$Updater類。針對這兩種情況，看了一下源碼，基本排除。

五、大量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 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。

CLOSE_WAIT 從上面的圖可以看出來，如果一直保持在CLOSE_WAIT 狀態，那么只有一種情況，就是在對方關閉連接之后，服務器程序自己沒有進一步發出ack 信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，于是這個資源就一直被程序占著。個人覺得這種情況，通過服務器內核參數也沒辦法解決，服務器對于程序搶占的資源沒有主動回收的權利，除非終止程序運行。

由于咱們自己使用的是HttpClient ，并且遇到了大量CLOSE_WAIT 的情況。所以懷疑這個點可能出了問題。

查看了咱們的httpClient 的寫法需要改正：

HttpGet get = newHttpGet(url.toString());

InputStream ins = null;

try{

HttpResponse response = excuteHttp(httpClient, get);

// HttpResponse response = httpClient.execute(get);

if(response.getStatusLine().getStatusCode() != 200) {

thrownewMapabcPoiRequestException(

"Http response status is not OK");

}

這種寫法意味著一旦出現非200 的連接,InputStream ins 根本就不會被賦值，這個連接將永遠僵死在連接池里頭.

解決方法：

if(response.getStatusLine().getStatusCode() != 200) {

get.abort();

thrownewMapabcPoiRequestException(

"Http response status is not OK");

}

應該改為顯示調用HttpGet 的abort ，這樣就會直接中止這次連接，我們在遇到異常的時候應該顯示調用，因為無法保證異常是在InputStream in 賦值之后才拋出。但是這種情況也是發生在httpClient 后端的服務出現了沒有響應的情況，

轉載于:https://blog.51cto.com/liuer/1338758

總結

以上是生活随笔為你收集整理的tomcat装死原因汇总的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。