快捷導(dǎo)航

SpringBoot?Seata?死鎖問題排查記錄

更新時(shí)間：2023年12月07日 09:08:47 作者：廢物大師兄

這篇文章主要介紹了SpringBoot?Seata?死鎖問題排查,本文給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

現(xiàn)象描述：Spring Boot項(xiàng)目，啟動(dòng)的時(shí)候卡住了，一直卡在那里不動(dòng)，沒有報(bào)錯(cuò)，也沒有日志輸出

但是，奇怪的是，本地可以正常啟動(dòng)

好吧，姑且先不深究為什么本地可以啟動(dòng)而部署到服務(wù)器上就無法啟動(dòng)的問題，這個(gè)不是重點(diǎn)，重點(diǎn)是怎么讓它啟動(dòng)起來。（PS：我猜測(cè)可能是環(huán)境不同造成的，包括操作系統(tǒng)不同和JDK版本不同）

遇到這種情況，我先用jstack查看堆棧情況，果然發(fā)現(xiàn)了死鎖

拿到j(luò)stack的完整信息，然后仔細(xì)排查，看不懂的話也可以借助工具

分析了每個(gè)被阻塞的線程之后，發(fā)現(xiàn)main線程和timeoutChecker_1_1互相等待對(duì)方持有的鎖，從而形成了死鎖

可以通過 jconsole 和 jvisualvm 查看

需要注意，如果是查看遠(yuǎn)程進(jìn)程，則需要加一些啟動(dòng)參數(shù)

-Dcom.sun.management.jmxremote：啟用JMX
-Dcom.sun.management.jmxremote.port=<端口號(hào)>：指定JMX遠(yuǎn)程連接的端口號(hào)
-Dcom.sun.management.jmxremote.authenticate=false：禁用JMX遠(yuǎn)程連接的認(rèn)證
-Dcom.sun.management.jmxremote.ssl=false：禁用JMX遠(yuǎn)程連接的SSL加密

于是，我又重啟啟動(dòng)

java -jar -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false app.jar

通過jps或者ps命令查找應(yīng)用的pid

用jvisualvm查看也可以，不再贅述，結(jié)果都是一樣的

好了，工具介紹到此為止，下面重點(diǎn)看代碼

main線程持有<0x00000000c07a33d8>這個(gè)對(duì)象的鎖，同時(shí)它還需要<0x00000000ff295ca8>對(duì)象的鎖，而timeoutChecker_1_1線程正好相反，于是死鎖了

main線程很好理解，就是我們這個(gè)SpringBoot應(yīng)用的主線程，但是timeoutChecker_1_1線程是哪兒來的呢，通過分析發(fā)現(xiàn)它來自Seata

對(duì)了，該項(xiàng)目中Spring Boot版本是2.6.6，Seata版本是1.4.2

找到timeoutChecker的出處了

延遲60秒啟動(dòng)定時(shí)任務(wù)，每隔10秒執(zhí)行一次，調(diào)用io.seata.core.rpc.netty.NettyClientChannelManager#reconnect()

記住這一行，首先調(diào)用RegistryFactory.getInstance()獲取一個(gè)RegistryService，然后調(diào)用RegistryService對(duì)象的lookup()方法

接著看1.4.2

最重要的是 EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);

所以，ExtConfigurationProvider 是 SpringBootConfigurationProvider

回到seata-1.4.2，可以看到這里調(diào)用了applicationContext.getBean()，于是DefaultListableBeanFactory.getBean()

可以看到，getSingletonFactoryBeanForTypeCheck()方法里，對(duì)singletonObjects加了同步鎖

凡是通過DefaultSingletonBeanRegistry#getSingleton()獲取單例Bean的都會(huì)先對(duì)singletonObjects加鎖

接下來看lookup

可以看到，NacosRegistryServiceImpl的lookup()這里也加了鎖。另外，getNamingProperties()的時(shí)候由于再次用到了ConfigurationFactory.CURRENT_FILE_INSTANCE，所以又到了SpringBootConfigurationProvider#provide()

至此，Seata整個(gè)定時(shí)任務(wù)啟動(dòng)的主要邏輯我們都梳理完了，幾處加鎖的也都找到了

這些加鎖的地方也就是容易出現(xiàn)死鎖的地方

死鎖是由于加鎖順序不一致造成的

下面看main線程啟動(dòng)

由于SeataDataSourceBeanPostProcessor實(shí)現(xiàn)了BeanPostProcessor接口，所以在創(chuàng)建容器之后會(huì)回調(diào)其postProcessAfterInitialization()方法

所以，最終還是調(diào)NettyClientChannelManager#reconnect()

Spring啟動(dòng)的時(shí)候去創(chuàng)建Spring容器，后面就是Spring那一套

ConfigurableApplicationContext#refresh()

ServletWebServerApplicationContext#refresh()

不再贅述

由于需要注入依賴，所以，這個(gè)過程中肯定會(huì)多次調(diào)用 AbstractBeanFactory.getBean()

前面我們講過，DefaultSingletonBeanRegistry.getSingleton() 時(shí)是加了鎖的。因此，main線程很有可能會(huì)先持有該鎖，當(dāng)初始化到Seata的時(shí)候，又要獲取該鎖，于是出現(xiàn)了鎖爭(zhēng)用。

由于兩個(gè)線程對(duì)同一資源的加鎖順序不一致，導(dǎo)致死鎖。

由于timeoutChecker是定時(shí)任務(wù)每隔10秒啟一次，所以第二次加鎖順序變成231

好了，關(guān)于main線程和timeoutChecker線程死鎖的分析就先到這里了

現(xiàn)在，回到項(xiàng)目中來，由于我們的項(xiàng)目中有一個(gè)比較耗時(shí)的操作，超時(shí)時(shí)間固定是60秒，這個(gè)方法本來應(yīng)該在Seata代理數(shù)據(jù)源之后做，不知道為什么服務(wù)器上先執(zhí)行了，導(dǎo)致main線程等待了60秒，之后才執(zhí)行SeataDataSourceBeanPostProcessor#postProcessAfterInitialization()