背景

技术背景：Nacos+SpringCloud+redis

问题描述

补救措施

问题分析

工具：jca4614.jar

1. cmd执行命令，打开可视化面板

2. 点击左上角文件夹，选择.dump文件打开

3. 可以从窗口中看到简要分析



其中有52%的线程处于Waiting on condition状态，对应方法为getBean()

4. 右键点击文件，选择查看线程详情

5. 选择按堆栈深度排序，可以看到堆栈顶部的线程

6. 在右边查看详情



找到这里除框架外我们自己的代码，可以看到线程卡在了A类中的name()方法；
这里粘贴部分代码如下：
 
根据nacos动态配置刷新的过程可以判断，这里刷新动态配置后，销毁了相关的全部bean，此时业务走到B类，在初始化B类时，调用了这里的构造方法，从而用到了A类中的name()方法。
但是name()方法仅返回了String，一般不会引起死锁，因此我们看向上一层堆栈。
 



很快定位到问题所在，这里看到在A类中有一个lock的动作，而这里lock是通过redis进行操作：
这里完善一下A中的代码
同时根据堆栈中信息可以得出，这里正在等待redissonClient.getLock(key).lock(time, TimeUnit.MILLISECONDS);
此时基本可以定位到此线程卡死的位置了，再通过kibana查询日志得出，52线程早在凌晨三点便已卡住。
 

现场重现

1. 凌晨三点，52线程卡住，此线程由主线程新建，此时主线程仅等待2.5秒，因此52线程的卡住状态不会影响到线上业务。

2. 修改配置，发出动态刷新指令；

3. 此服务中开始销毁bean；

4. 尽管A未被销毁，但已经被程序认为销毁成功；

5. 新业务到达，开始重构bean；

6. 在调用A.name()时，由于bean是单例，此实例被52线程持有，因此无法访问方法；

7. 所有进程开始等待B类构建；

8. 服务业务持续进入，消耗线程储备；

9. 服务完全卡死不动。

经验教训