SpringBoot Seata 死鎖問題排查

原創

廢物大師兄

2023-12-07 14:03

現象描述：Spring Boot項目，啓動的時候卡住了，一直卡在那裏不動，沒有報錯，也沒有日誌輸出

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

好吧，姑且先不深究爲什麼本地可以啓動而部署到服務器上就無法啓動的問題，這個不是重點，重點是怎麼讓它啓動起來。（PS：我猜測可能是環境不同造成的，包括操作系統不同和JDK版本不同）

遇到這種情況，我先用jstack查看堆棧情況，果然發現了死鎖

拿到jstack的完整信息，然後仔細排查，看不懂的話也可以藉助工具

分析了每個被阻塞的線程之後，發現main線程和timeoutChecker_1_1互相等待對方持有的鎖，從而形成了死鎖

可以通過 jconsole 和 jvisualvm 查看

需要注意，如果是查看遠程進程，則需要加一些啓動參數

-Dcom.sun.management.jmxremote：啓用JMX
-Dcom.sun.management.jmxremote.port=<端口號>：指定JMX遠程連接的端口號
-Dcom.sun.management.jmxremote.authenticate=false：禁用JMX遠程連接的認證
-Dcom.sun.management.jmxremote.ssl=false：禁用JMX遠程連接的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命令查找應用的pid

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

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

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

main線程很好理解，就是我們這個SpringBoot應用的主線程，但是timeoutChecker_1_1線程是哪兒來的呢，通過分析發現它來自Seata

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

找到timeoutChecker的出處了

延遲60秒啓動定時任務，每隔10秒執行一次，調用io.seata.core.rpc.netty.NettyClientChannelManager#reconnect()

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

接着看1.4.2

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

所以，ExtConfigurationProvider 是 SpringBootConfigurationProvider

回到seata-1.4.2，可以看到這裏調用了applicationContext.getBean()，於是DefaultListableBeanFactory.getBean()

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

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

接下來看lookup

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

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

這些加鎖的地方也就是容易出現死鎖的地方

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

下面看main線程啓動

由於SeataDataSourceBeanPostProcessor實現了BeanPostProcessor接口，所以在創建容器之後會回調其postProcessAfterInitialization()方法

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

Spring啓動的時候去創建Spring容器，後面就是Spring那一套

ConfigurableApplicationContext#refresh()

ServletWebServerApplicationContext#refresh()

不再贅述

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

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

由於兩個線程對同一資源的加鎖順序不一致，導致死鎖。

由於timeoutChecker是定時任務每隔10秒啓一次，所以第二次加鎖順序變成231

好了，關於main線程和timeoutChecker線程死鎖的分析就先到這裏了

現在，回到項目中來，由於我們的項目中有一個比較耗時的操作，超時時間固定是60秒，這個方法本來應該在Seata代理數據源之後做，不知道爲什麼服務器上先執行了，導致main線程等待了60秒，之後才執行SeataDataSourceBeanPostProcessor#postProcessAfterInitialization()