上一篇博文给大家分享了使用Windbg分析内存泄露问题:
Windbg程序调试系列2-内存泄露问题
本篇我们继续跟大家分享,如何分析解决线程阻塞问题。
从根本上讲,线程阻塞属于程序Hang的一种,其表现主要有:
1. 随着请求的增加,线程数一直增加,可能会把线程池打爆
2. 低CPU使用率(被阻塞后的CPU使用率降低)
3. 请求没有返回,客户端一直在等待,直至Timeout。
那么,从线程状态上看,什么是阻塞? 一个线程经历的5个状态,创建,就绪,运行,阻塞,终止。各个状态的转换条件如下图:
上图中有个阻塞状态,就是说当线程中调用某个函数,需要IO请求,或者暂时得不到竞争资源的,操作系统会把该线程阻塞起来,避免浪费CPU资源,等到得到了资源,再变成就绪状态,等待CPU调度运行。
线程发生阻塞的现象就是,进程的线程数会越来越多!
线程阻塞问题的分析思路:
持续请求过程中,抓两个或者三个Dump,看线程增加的速度,每次抓Dump间隔30s或者1分钟
对比的看每个Dump中:
1. 查看线程池的大小:!threadpool,有时间间隔两个Dump对比着看,看线程池的线程数的增长情况:
2. 查看线程的分类和线程的状态 !threads,从下图可以看出,后台线程一直在增加
3. 查看线程阻塞 !syncblk,也是看这两个dump,对比着看
我们发现:
第一个Dump中95号线程 阻塞了(1021-1)/2=510个线程
第二个Dump中79号线程 阻塞了(1099-1)/2=549个线程
95号线程独占的对象资源 00000026ba7c4dc0 (System.Object)
79号线程独占的对象资源也是00000026ba7c4dc0(System.Object)
两个线程同时锁住了同一个资源!00000026ba7c4dc0(System.Object)
此时,线程阻塞问题已经确定,接下来,我们要重点分析阻塞的根源线程(持有什么资源不释放,导致其他线程在等待),95号线程、79号线程
4. 查看阻塞线程的根源线程、线程请求的资源对象 、被阻塞的线程数
例如 95号线程:
1 查看阻塞根源线程的堆栈 2 ~95s 3 !clrstack
通过线程堆栈,我们在栈顶发现,95号线程,在等待Socket Server返回,具体再等哪个Socket Server?
通过以下命令找出当前线程堆栈上的Socket对象
!dso
这样我们就定位出95号线程在做什么,在等待什么:
95号线程在等待SocketServer 10.*.*.*:80返回数据,独占资源:00000026ba7c4dc0(System.Object)
同时我们通过线程堆栈看到了我们自己的一个TCP通讯类TCPInvoker, 在创建一个新的TCP连接,TCPInvoker类的代码需要重点关注,继续看!
我们继续看79号线程:
1 ~79s 2 !clrstack
通过79号线程的堆栈和阻塞情况可以发现:
79号线程Monitor.Enter(object),在请求资源的独占锁:00000026ba7c4dc0(System.Object)
TCPInvoker卡在了GetInvoker方法上。我们需要看看TCPInvoker的代码了
5. 分析线程阻塞的原因,改进代码
从如下的代码中,我们能看到:
95号线程是执行到了GetInvoker方法的Create,Create中在等待Socket Server返回,此时如果Socket Server没有响应,超时时间默认是5s,会一直持有资源00000026ba7c4dc0(System.Object)不释放
79号线程也执行到了GetInvoker方法,但是在Lock时,等待95号线程释放资源:00000026ba7c4dc0(System.Object)
随着请求越来越多,超时+重试连接Socket Server,导致线程阻塞住了。
解决方案:1. 分析Socket Server为什么连不上 2. 优化改进TCPInvoker内部的业务逻辑,减少超时和重试时间,减少阻塞的产生几率。
好了,上面就是这次分享的Windbg调试线程阻塞问题的细节和过程,总结一下:
线程阻塞问题的分析思路:
周国庆
2018/11/1