线程问题怎么排查

·  阅读 58

线程状态的定义

可见在 JDK 中定义的线程状态总共六种,各状态在特定条件下可以转换,其组成了一个线程的生命周期,为了方便理解,对其状态和转换整理成了列表和状态图的形式。

状态描述
NEW线程新建但是还没有 start 的时候,即 new Thread()
RUNNABLE调用了 Thread 的 start() 方法,此时线程可运行,但是也有可能需要等待其他操作系统资源,比如处理器资源,当获取到处理器资源之后,则进入 RUNNING 状态
BLOCKED当进入同步代码块时,如果需要等待获取锁,那么就会被阻塞进入该状态
WAITING由于执行了 Object.wait()、`Thread.join()、LockSupport.park() 进入了等待状态
TIMED_WAITING由于执行了 Thread.sleep(long)、Object.wait(long)、Thread.join(long)、LockSupport.parkNanos、LockSupport.parkUntil,进入了有限时长的等待状态
TERMINATED线程 run 方法执行结束

线程运行的几个概念

  • 临界区

临界区用来表示一种公共资源或者说是共享数据,可以被多个线程使用。但是每一次,只能有一个线程使用它,一旦临界区资源被占用,其他线程要想使用这个资源,就必须等待。

  • 死锁

死锁是进程死锁的简称,是指多个进程循环等待他方占有的资源而无限的僵持下去的局面。

  • 活锁

假设有两个线程1、2,它们都需要资源 A/B,假设1号线程占有了 A 资源,2号线程占有了 B 资源;由于两个线程都需要同时拥有这两个资源才可以工作,为了避免死锁,1号线程释放了 A 资源占有锁,2号线程释放了 B 资源占有锁;此时 AB 空闲,两个线程又同时抢锁,再次出现上述情况,此时发生了活锁。

简单类比,电梯遇到人,一个进的一个出的,对面占路,两个人同时往一个方向让路,来回重复,还是堵着路。

如果线上应用遇到了活锁问题,恭喜你中奖了,这类问题比较难排查。

  • 饥饿

饥饿是指某一个或者多个线程因为种种原因无法获得所需要的资源,导致一直无法执行。

线程问题排查

在多线程程序中,如果出现的问题是数据异常类的问题,比较难排查需要一点点的检查代码。如果说是资源类的问题排查起来相对来说比较简单。常用的命令就是 top/jps 以及 ps 定位出是哪个进程。然后通过 jstack 命令打出这个进程的全部线程堆栈,接下来就是分析打印的堆栈信息了。在堆栈信息里面打印的线程状态有:

 死锁,Deadlock(重点关注)
 执行中,Runnable  
 等待资源,Waiting on condition(重点关注)
 等待获取监视器,Waiting on monitor entry(重点关注)
 暂停,Suspended
 对象等待中,Object.wait() 或 TIMED_WAITING
 阻塞,Blocked(重点关注) 
 停止,Parked
复制代码

可能存在的情况有:

  • 线程状态为“Runnable”。

该状态表示线程具备所有运行条件,在运行队列中准备操作系统的调度,或者正在运行。

  • 线程状态为“waiting for monitor entry”。

意味着它在等待进入一个临界区,所以它在“Entry Set”队列中等待。

此时线程状态一般都是 Blocked:java.lang.Thread.State: BLOCKED (on object monitor)。

  • 线程状态为“waiting on condition”。

说明它在等待另一个条件的发生,来把自己唤醒,或者干脆它是调用了 sleep(N)。此时线程状态大致为以下几种:

(1) java.lang.Thread.State: WAITING (parking):一直等那个条件发生;

(2) java.lang.Thread.State: TIMED_WAITING (parking或sleeping):定时的,那个条件不到来,也将定时唤醒自己。

  • 如果大量线程在“waiting for monitor entry”。

可能是一个全局锁阻塞住了大量线程。

如果短时间内打印的 thread dump 文件反映,随着时间流逝,waiting for monitor entry 的线程越来越多,没有减少的趋势,可能意味着某些线程在临界区里呆的时间太长了,以至于越来越多新线程迟迟无法进入临界区。

  • 如果大量线程在“waiting on condition”:

可能是它们又跑去获取第三方资源,尤其是第三方网络资源,迟迟获取不到 Response,导致大量线程进入等待状态。

所以如果你发现有大量的线程都处在 Wait on condition,从线程堆栈看,正等待网络读写,这可能是一个网络瓶颈的征兆,因为网络阻塞导致线程无法执行。

  • 线程状态为“in Object.wait()”:

说明它获得了监视器之后,又调用了 java.lang.Object.wait() 方法。

每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”,而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。

当线程获得了 Monitor,如果发现线程继续运行的条件没有满足,它则调用对象(一般就是被 synchronized 的对象)的 wait() 方法,放弃了 Monitor,进入“Wait Set”队列。

此时线程状态大致为以下几种:

java.lang.Thread.State: TIMED_WAITING (on object monitor);

java.lang.Thread.State: WAITING (on object monitor);

线程问题排查工具

cpu过高分析原因,到代码级别

解决过程:
1,根据top命令,发现PID为2633的Java进程占用CPU高达300%,出现故障。
2,找到该进程后,如何定位具体线程或代码呢,首先显示线程列表,并按照CPU占用高的线程排序:

[root@localhost logs]# ps -mp 2633 -o THREAD,tid,time | sort -rn
复制代码

显示结果如下:

USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME
root     10.5  19    - -         -      -  3626 00:12:48
root     10.1  19    - -         -      -  3593 00:12:16
复制代码

找到了耗时最高的线程3626,占用CPU时间有12分钟了! 将需要的线程ID转换为16进制格式:

[root@localhost logs]# printf "%x\n" 3626
e18
复制代码

最后打印线程的堆栈信息:

[root@localhost logs]# jstack 2633 |grep e18 -A 30
复制代码

脚本 show-busy-java-threads ,自动化上面的排查过程,

一键输出 javaCPU消耗高的线程:

github.com/oldratlee/u…

top命令查看线程cpu

//间隔1秒(-d 1),输出一次(-n 1)
top -Hp pid -d 1 -n 1

//打印System_Server进程各个线程的Java调用栈,根据线程状态及调用栈来更进一步定位问题点
kill -3 pid 
复制代码

扫描二维码,关注公众号“猿必过”

file

回复 “面试题” 自行领取吧。

微信群交流讨论,请添加微信号:zyhui98,备注:面试题加群

本文由猿必过 YBG 发布 禁止未经授权转载,违者依法追究相关法律责任 如需授权可联系:zhuyunhui@yuanbiguo.com

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改