現象描述：Spring Boot項目，啟動的時候卡住了，一直卡在那裡不動，沒有報錯，也沒有日誌輸出 但是，奇怪的是，本地可以正常啟動 好吧，姑且先不深究為什麼本地可以啟動而部署到伺服器上就無法啟動的問題，這個不是重點，重點是怎麼讓它啟動起來。（PS：我猜測可能是環境不同造成的，包括操作系統不同和JD ...
現象描述：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
