VB.net 2010 视频教程 VB.net 2010 视频教程 python基础视频教程
SQL Server 2008 视频教程 c#入门经典教程 Visual Basic从门到精通视频教程
当前位置:
首页 > 编程开发 > Java教程 >

  • 线程问题怎么排查

线程状态的定义

可见在 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消耗高的线程：

https://github.com/oldratlee/useful-scripts/blob/master/docs/java.md#-show-busy-java-threads

top命令查看线程cpu

//间隔1秒（-d 1），输出一次（-n 1）
top -Hp pid -d 1 -n 1

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

出处：https://www.cnblogs.com/javago/p/14472580.html


相关教程