(精华)2020年9月6日.NETCore程序调试Windbg(线程阻塞问题)

从根本上讲&＃xff0c;线程阻塞属于程序Hang的一种&＃xff0c;其表现主要有&＃xff1a;

1. 随着请求的增加&＃xff0c;线程数一直增加&＃xff0c;可能会把线程池打爆

2. 低CPU使用率&＃xff08;被阻塞后的CPU使用率降低&＃xff09;

3. 请求没有返回&＃xff0c;客户端一直在等待&＃xff0c;直至Timeout。

那么&＃xff0c;从线程状态上看&＃xff0c;什么是阻塞&＃xff1f; 一个线程经历的5个状态&＃xff0c;创建&＃xff0c;就绪&＃xff0c;运行&＃xff0c;阻塞&＃xff0c;终止。各个状态的转换条件如下图&＃xff1a;

上图中有个阻塞状态&＃xff0c;就是说当线程中调用某个函数&＃xff0c;需要IO请求&＃xff0c;或者暂时得不到竞争资源的&＃xff0c;操作系统会把该线程阻塞起来&＃xff0c;避免浪费CPU资源&＃xff0c;等到得到了资源&＃xff0c;再变成就绪状态&＃xff0c;等待CPU调度运行。

线程发生阻塞的现象就是&＃xff0c;进程的线程数会越来越多&＃xff01;

线程阻塞问题的分析思路&＃xff1a;

持续请求过程中&＃xff0c;抓两个或者三个Dump&＃xff0c;看线程增加的速度&＃xff0c;每次抓Dump间隔30s或者1分钟
对比的看每个Dump中&＃xff1a;

1. 线程池的大小 !threadpool
2. 线程的分类和状态 !threads
3. 查看线程阻塞 !syncblk
4. 查看阻塞线程的根源线程、线程请求的资源对象 、被阻塞的线程数
5. 查看阻塞根源线程的堆栈~Xs !clrstack
6. 分析线程阻塞的原因&＃xff0c;改进代码

1. 查看线程池的大小&＃xff1a;!threadpool&＃xff0c;有时间间隔两个Dump对比着看&＃xff0c;看线程池的线程数的增长情况&＃xff1a;

2. 查看线程的分类和线程的状态 !threads&＃xff0c;从下图可以看出&＃xff0c;后台线程一直在增加

3. 查看线程阻塞 !syncblk&＃xff0c;也是看这两个dump&＃xff0c;对比着看

我们发现&＃xff1a;

第一个Dump中95号线程 阻塞了&＃xff08;1021-1&＃xff09;/2&＃61;510个线程
第二个Dump中79号线程 阻塞了&＃xff08;1099-1&＃xff09;/2&＃61;549个线程

95号线程独占的对象资源 00000026ba7c4dc0 &＃xff08;System.Object&＃xff09;

79号线程独占的对象资源也是00000026ba7c4dc0&＃xff08;System.Object&＃xff09;

两个线程同时锁住了同一个资源&＃xff01;00000026ba7c4dc0&＃xff08;System.Object&＃xff09;

此时&＃xff0c;线程阻塞问题已经确定&＃xff0c;接下来&＃xff0c;我们要重点分析阻塞的根源线程&＃xff08;持有什么资源不释放&＃xff0c;导致其他线程在等待&＃xff09;&＃xff0c;95号线程、79号线程

4. 查看阻塞线程的根源线程、线程请求的资源对象 、被阻塞的线程数

例如 95号线程&＃xff1a;

1 查看阻塞根源线程的堆栈
2 ~95s
3 !clrstack


通过线程堆栈&＃xff0c;我们在栈顶发现&＃xff0c;95号线程&＃xff0c;在等待Socket Server返回&＃xff0c;具体再等哪个Socket Server&＃xff1f;

通过以下命令找出当前线程堆栈上的Socket对象

!dso


这样我们就定位出95号线程在做什么&＃xff0c;在等待什么&＃xff1a;

95号线程在等待SocketServer 10...*:80返回数据&＃xff0c;独占资源&＃xff1a;00000026ba7c4dc0&＃xff08;System.Object&＃xff09;

同时我们通过线程堆栈看到了我们自己的一个TCP通讯类TCPInvoker, 在创建一个新的TCP连接&＃xff0c;TCPInvoker类的代码需要重点关注&＃xff0c;继续看&＃xff01;

我们继续看79号线程&＃xff1a;

1 ~79s
2 !clrstack


通过79号线程的堆栈和阻塞情况可以发现&＃xff1a;

79号线程Monitor.Enter&＃xff08;object&＃xff09;&＃xff0c;在请求资源的独占锁&＃xff1a;00000026ba7c4dc0&＃xff08;System.Object&＃xff09;

TCPInvoker卡在了GetInvoker方法上。我们需要看看TCPInvoker的代码了

5. 分析线程阻塞的原因&＃xff0c;改进代码

从如下的代码中&＃xff0c;我们能看到:

95号线程是执行到了GetInvoker方法的Create&＃xff0c;Create中在等待Socket Server返回&＃xff0c;此时如果Socket Server没有响应&＃xff0c;超时时间默认是5s&＃xff0c;会一直持有资源00000026ba7c4dc0&＃xff08;System.Object&＃xff09;不释放

79号线程也执行到了GetInvoker方法&＃xff0c;但是在Lock时&＃xff0c;等待95号线程释放资源&＃xff1a;00000026ba7c4dc0&＃xff08;System.Object&＃xff09;

随着请求越来越多&＃xff0c;超时&＃43;重试连接Socket Server&＃xff0c;导致线程阻塞住了。


解决方案&＃xff1a;1. 分析Socket Server为什么连不上 2. 优化改进TCPInvoker内部的业务逻辑&＃xff0c;减少超时和重试时间&＃xff0c;减少阻塞的产生几率。

好了&＃xff0c;上面就是这次分享的Windbg调试线程阻塞问题的细节和过程&＃xff0c;总结一下&＃xff1a;

线程阻塞问题的分析思路&＃xff1a;

1. 线程池的大小 !threadpool
2. 线程的分类和状态 !threads
3. 查看线程阻塞 !syncblk
4. 查看阻塞线程的根源线程、线程请求的资源对象 、被阻塞的线程数
5. 查看阻塞根源线程的堆栈~Xs !clrstack
6. 分析线程阻塞的原因&＃xff0c;改进代码