线程状态的定义
可见在 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/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
> 本文由猿必过 [YBG]发布
> 禁止未经授权转载，违者依法追究相关法律责任
共同学习，写下你的评论
评论加载中...
作者其他优质文章
