Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

本文首發於 vivo互聯網技術 微信公衆號 
鏈接:https://mp.weixin.qq.com/s/-OcCDI4L5GR8vVXSYhXJ7w
作者:黃衛兵、陳錦霞

一、Tomcat容器 9.0.26 版本 Deadlock 問題

1.1 問題現象

1.1.1  發生 Deadlock 的背景

某接口/get.do壓測,3分鐘後,成功事務數TPS由1W驟降至0。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

1.1.2  Tomcat服務器出現大量的CLOSE_WAIT

被壓測服務器,出現TCP CLOSE_WAIT狀態個數在200~2W左右。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

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

通過jstack打印Tomcat堆棧信息,發現“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"

1.2.1  快速修復方案

內部討論後,認爲當前Tomcat版本可能有Bug。不影響項目進度,簡單修改方案把SpringBoot 使用的Tomcat 9.0.26 降級到Tomcat 8。降級後再次壓測,沒有發現問題。基本上可以確定Tomcat 9.0.26 應該是存在 Deadlock 問題。

1.3  問題進一步跟蹤

1.3.1  向Apache社區的反饋

爲了確認問題,我們試着給Tomcat提交Bug反饋。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

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

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

1.4 問題原因分析

明確了死鎖的過程,但是哪個環節出了問題呢。這就需要深入到源碼層去定位問題。首先需要下載OpenJDK 源碼,然後是Tomcat 9.0.26 的源碼。根據堆棧信息,定位到相應的代碼位置。我們理出如下圖Tomcat 9.0.26死鎖流程說明。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

要比較好的理解上圖,需要對於NIO有一定的瞭解。在Tomcat中NIO主要是理解NIO Endpoint。

Poller是對於Selector的一個封裝,而線程名爲exec-xx的執行線程是Channel的封裝。在NIO中Channel註冊到Selector然後通過SelectionKey來記錄對應關係。到此,主角都上場了。

Poller的run方法作爲後臺線程一直在輪詢(select)準備好的SelectionKey,在輪詢的時候也順便需要把cancelledKey中的SelectionKey給反註冊。執行線程EXEC-XX在處理時會先判斷連接的狀態,比如失敗、異常等情況會調用Channel的close方法去關閉連接。

而Channel的close實際只是把SelectionKey加入到cancelledKey。兩者都需要先鎖定,但鎖定的順序不一致,從而導致死鎖。

1.4.1  與Tomcat開發者的交流

在提交Bug後,很快得到了Remy Maucherat的回覆,首先他提到這個NIO內部的死鎖。然後我們提到NIO內部的死鎖是由於Poller.run和Poller.canceledKey在併發時導到的。

Remy Maucherat很快就進行了修復,主要是把Poller.canceledKey中close移到了finally中去執行,也就是先讓Poller.run獲得鎖。

在得到修復後,我們使用替換後的代碼進行了再次壓測,死鎖問題沒有出現了。Remy Maucherat同時提到在最新的OpenJDK中相關問題的修復,但只會出現在jdk 11和14版本。

溝通中的詳情見下圖。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

1.4.2  Github上修復的驗證

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

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

1.5 結果驗證

使用 https://github.com/apache/tomcat/commit/9b1a8b67bffe462fc745b19e15ed59c37e2e1dcf 提供修復後代碼,重新打包tomcat-embed-core.jar 替換9.X.XX的再次壓測,TPS平穩在1.5W左右。

Tomcat 9.0.26 高併發場景下DeadLock問題排查與修復

到此問題基本是定位清楚,並得到了修復。Remy Maucherat也回覆到“The fix will be in Tomcat 9.0.31+”。

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

二、相關鏈接與參考

  1. OpenJdk源碼下載

  2. Tomcat 源碼

  3. 來自阿里云溪社區:斷網故障時Mtop觸發Tomcat高併發場景下的BUG排查和修復

  4. 深度解讀Tomcat中的NIO模型 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章