现象描述：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线程持有这个对象的锁，同时它还需要对象的锁，而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()
不再赘述
由于需要注入依赖，所以，这个过程中肯定会多次调用 AbstractB服务器托管网eanFactory.getBean()
前面我们讲过，DefaultSingletonBeanRegistry.getSingleton() 时是加了锁的。因此，main线程很有可能会先持有该锁，当初始化到Seata的时候，又要获取该锁，于是出现了锁争用。
由于两个线程对同一资源的加锁顺序不一致，导致死锁。
由于timeoutChecker是定时任务每隔10秒启一次，所以第二次加锁顺序变成231
好了，关于main线程和timeoutChecker线程死锁的分析就先到这里了
现在，回到项目中来，由于我们的项目中有一个比较耗时的操作，超时时间固定是60秒，这个方法本来应该在Seata代理数据源之后做，不知道为什么服务器上先执行了，导致main线程等待了60秒，之后才执行SeataDataSourceBeanPostProcessor#postProcessAfterInitialization()
最终解决方法时将@PostConstruct注解去掉，不在容器初始化的时候取做这么耗时的操作
如果采用Seata-1.5.2版本的话，可能也不会出现死锁问题
参考
jconsole远程连接失败如何解决 – 问答 – 亿速云 (yisu.com)
htt服务器托管网ps://www.zhihuclub.com/179001.shtml
https://zhuanlan.zhihu.com/p/619203844
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
相关推荐: 服务器常见问题排查（一）——cpu占用高、上下文频繁切换、频繁GC
一般而言cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。 使用jstack排查占用率问题 当使用jstack排查占用率问题时，…
