這篇文章給大家分享的是有關(guān)Tomcat 9.0.26高并發(fā)場(chǎng)景下DeadLock問題怎么處理的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

10年積累的成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有泰來免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

一、Tomcat容器 9.0.26 版本 Deadlock 問題

1.1 問題現(xiàn)象

1.1.1  發(fā)生 Deadlock 的背景

某接口/get.do壓測(cè)，3分鐘后，成功事務(wù)數(shù)TPS由1W驟降至0。

1.1.2  Tomcat服務(wù)器出現(xiàn)大量的CLOSE_WAIT

被壓測(cè)服務(wù)器，出現(xiàn)TCP CLOSE_WAIT狀態(tài)個(gè)數(shù)在200~2W左右。

1.2 初步定位：線程堆棧信息入手

通過jstack打印Tomcat堆棧信息，發(fā)現(xiàn)“Found 1 deadlock”

Found one Java-level deadlock:
=============================
"http-nio-8080-exec-409":
waiting to lock monitor 0x00007f064805aa78 (object 0x00000006c0ebf148, a java.util.HashSet),
which is held by "http-nio-8080-ClientPoller"
"http-nio-8080-ClientPoller":
waiting to lock monitor 0x00007f05e8061058 (object 0x00000007bfe40a70, a java.lang.Object),
which is held by "http-nio-8080-exec-205"
"http-nio-8080-exec-205":
waiting to lock monitor 0x00007f0614018448 (object 0x00000006c0e8e088, a java.util.HashSet),
which is held by "http-nio-8080-BlockPoller"
"http-nio-8080-BlockPoller":
waiting to lock monitor 0x0000000001ed06e8 (object 0x00000007bfe110f8, a java.lang.Object),
which is held by "http-nio-8080-exec-380"
"http-nio-8080-exec-380":
waiting to lock monitor 0x00007f064805aa78 (object 0x00000006c0ebf148, a java.util.HashSet),
which is held by "http-nio-8080-ClientPoller"[object Object]

1.2.1  快速修復(fù)方案

內(nèi)部討論后，認(rèn)為當(dāng)前Tomcat版本可能有Bug。不影響項(xiàng)目進(jìn)度，簡(jiǎn)單修改方案把SpringBoot 使用的Tomcat 9.0.26 降級(jí)到Tomcat 8。降級(jí)后再次壓測(cè)，沒有發(fā)現(xiàn)問題?；旧峡梢源_定Tomcat 9.0.26 應(yīng)該是存在 Deadlock 問題。

1.3  問題進(jìn)一步跟蹤

1.3.1  向Apache社區(qū)的反饋

為了確認(rèn)問題，我們?cè)囍oTomcat提交Bug反饋。

從堆棧信息來看，是3類線程5個(gè)線程由于加鎖的順序不致，從而相互等待發(fā)生了死鎖。圖形化上面加鎖的過程如下圖。

1.4 問題原因分析

明確了死鎖的過程，但是哪個(gè)環(huán)節(jié)出了問題呢。這就需要深入到源碼層去定位問題。首先需要下載OpenJDK 源碼，然后是Tomcat 9.0.26 的源碼。根據(jù)堆棧信息，定位到相應(yīng)的代碼位置。我們理出如下圖Tomcat 9.0.26死鎖流程說明。

要比較好的理解上圖，需要對(duì)于NIO有一定的了解。在Tomcat中NIO主要是理解NIO Endpoint。

Poller是對(duì)于Selector的一個(gè)封裝，而線程名為exec-xx的執(zhí)行線程是Channel的封裝。在NIO中Channel注冊(cè)到Selector然后通過SelectionKey來記錄對(duì)應(yīng)關(guān)系。到此，主角都上場(chǎng)了。

Poller的run方法作為后臺(tái)線程一直在輪詢（select）準(zhǔn)備好的SelectionKey，在輪詢的時(shí)候也順便需要把cancelledKey中的SelectionKey給反注冊(cè)。執(zhí)行線程EXEC-XX在處理時(shí)會(huì)先判斷連接的狀態(tài)，比如失敗、異常等情況會(huì)調(diào)用Channel的close方法去關(guān)閉連接。

而Channel的close實(shí)際只是把SelectionKey加入到cancelledKey。兩者都需要先鎖定，但鎖定的順序不一致，從而導(dǎo)致死鎖。

1.4.1  與Tomcat開發(fā)者的交流

在提交Bug后，很快得到了Remy Maucherat的回復(fù)，首先他提到這個(gè)NIO內(nèi)部的死鎖。然后我們提到NIO內(nèi)部的死鎖是由于Poller.run和Poller.canceledKey在并發(fā)時(shí)導(dǎo)到的。

Remy Maucherat很快就進(jìn)行了修復(fù)，主要是把Poller.canceledKey中close移到了finally中去執(zhí)行，也就是先讓Poller.run獲得鎖。

在得到修復(fù)后，我們使用替換后的代碼進(jìn)行了再次壓測(cè)，死鎖問題沒有出現(xiàn)了。Remy Maucherat同時(shí)提到在最新的OpenJDK中相關(guān)問題的修復(fù)，但只會(huì)出現(xiàn)在jdk 11和14版本。

溝通中的詳情見下圖。

1.4.2  Github上修復(fù)的驗(yàn)證

https://github.com/apache/tomcat/commit/9b1a8b67bffe462fc745b19e15ed59c37e2e1dcf

1.5 結(jié)果驗(yàn)證

使用  https://github.com/apache/tomcat/commit/9b1a8b67bffe462fc745b19e15ed59c37e2e1dcf 提供修復(fù)后代碼，重新打包tomcat-embed-core.jar 替換9.X.XX的再次壓測(cè)，TPS平穩(wěn)在1.5W左右。

到此問題基本是定位清楚，并得到了修復(fù)。Remy Maucherat也回復(fù)到“The fix will be in Tomcat 9.0.31+”。

目前Tomcat 最新版本是Tomcat 9.0.30，還需要耐心等待31版本更新。建議使用Tomcat 8版本。

感謝各位的閱讀！關(guān)于“Tomcat 9.0.26高并發(fā)場(chǎng)景下DeadLock問題怎么處理”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！