技術文章 » SpringBoot Seata 死鎖問題排查

SpringBoot Seata 死鎖問題排查

2023-12-06 21:01:31

現象描述：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()

最終解決方法時將@PostConstruct註解去掉，不在容器初始化的時候取做這麼耗時的操作

如果採用Seata-1.5.2版本的話，可能也不會出現死鎖問題

 

參考

jconsole遠端連線失敗如何解決 - 問答 - 億速雲 (yisu.com) 

https://www.zhihuclub.com/179001.shtml 

https://zhuanlan.zhihu.com/p/619203844