腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

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

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

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

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

但是，奇怪的是，本地可以正常啟動

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

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

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

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

可以通過 jconsole 和 jvisualvm 查看

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

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

于是，我又重啟啟動

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é)果都是一樣的

好了，工具介紹到此為止，下面重點看代碼

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

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

對了，該項目中Spring Boot版本是2.6.6，Seata版本是1.4.2

找到timeoutChecker的出處了

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

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

接著看1.4.2

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

所以，ExtConfigurationProvider 是 SpringBootConfigurationProvider

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

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

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

接下來看lookup

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

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

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

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

下面看main線程啟動

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

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

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

ConfigurableApplicationContext#refresh()

ServletWebServerApplicationContext#refresh()

不再贅述

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

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

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

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

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

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