定位常见Java性能和故障问题
概述
性能优化和故障处理一向是后端服务运维的重点,但是线上性能故障问题或者受限于业务产品逻辑不是经常出现,为了当出现问题的时候不会手忙脚乱,本篇文章来模拟下常见的几个Java性能故障,来学习怎么去分析和定位。
预备知识
既然是定位问题,肯定是需要借助工具,我们先了解下需要哪些工具可以帮忙定位问题。
一、Linux服务器状态查看工具
top命令
Linux top命令用于查看系统的运行状况,可以显示当前正在执行的进程的CPU使用率,内存使用率等系统信息。top -Hp pid 可以查看线程的系统资源使用情况。 语法: top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]
第一行,任务队列信息,同 uptime 命令的执行结果
系统时间:07:27:05
运行时间:up 1:57 min,
当前登录用户: 3 user
负载均衡(uptime) load average: 0.00, 0.00, 0.00
average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。
load average数据是每隔5秒钟检查一次活跃的进程数,然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量,结果高于5的时候就表明系统在超负荷运转了
第二行,Tasks — 任务(进程)
总进程:150 total, 运行:1 running, 休眠:149 sleeping, 停止: 0 stopped, 僵尸进程: 0 zombie
第三行,cpu状态信息
0.0%us【user space】— 用户空间占用CPU的百分比。
0.3%sy【sysctl】— 内核空间占用CPU的百分比。
0.0%ni【】— 改变过优先级的进程占用CPU的百分比
99.7%id【idolt】— 空闲CPU百分比
0.0%wa【wait】— IO等待占用CPU的百分比
0.0%hi【Hardware IRQ】— 硬中断占用CPU的百分比
0.0%si【Software Interrupts】— 软中断占用CPU的百分比
第四行,内存状态
1003020k total, 234464k used, 777824k free, 24084k buffers【缓存的内存量】
第五行,swap交换分区信息
2031612k total, 536k used, 2031076k free, 505864k cached【缓冲的交换区总量】
备注:
可用内存=free + buffer + cached
对于内存监控,在top里我们要时刻监控第五行swap交换分区的used,如果这个数值在不断的变化,说明内核在不断进行内存和swap的数据交换,这是真正的内存不够用了。
第四行中使用中的内存总量(used)指的是现在系统内核控制的内存数,
第四行中空闲内存总量(free)是内核还未纳入其管控范围的数量。
纳入内核管理的内存不见得都在使用中,还包括过去使用过的现在可以被重复利用的内存,内核并不把这些可被重新使用的内存交还到free中去,因此在linux上free内存会越来越少,但不用为此担心。
第六行,空行
第七行以下:各进程(任务)的状态监控
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级,正值表示低优先级
VIRT — 进程使用的虚拟内存总量,单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小,单位kb。RES=CODE+DATA
SHR — 共享内存大小,单位kb
S —进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计,单位1/100秒
COMMAND — 进程名称(命令名/命令行)
ps命令
Linux ps (英文全拼:process status)命令用于显示当前进程的状态,类似于 windows 的任务管理器。 语法: ps [options] [--help] 参数:
- ps 的参数非常多, 在此仅列出几个常用的参数并大略介绍含义
- -A 列出所有的进程
- -w 显示加宽可以显示较多的资讯
- -au 显示较详细的资讯
- -aux 显示所有包含其他使用者的行程,COMMAND字段内容会被截断
- -ef 显示所有包含其他使用者的行程,COMMAND字段内容不会被截断
实例 查看Java进程 ps -ef|grep java
vmstat命令
vmstat是一个指定周期和采集次数的虚拟内存检测工具,可以统计内存,CPU,swap的使用情况,它还有一个重要的常用功能,用来观察进程的上下文切换。 语法 vmstat [options] [–help] 实例:每隔10秒采集一次服务器状态
字段说明如下:
- r: 运行队列中进程数量(当数量大于CPU核数表示有阻塞的线程)
- b: 等待IO的进程数量
- swpd: 使用虚拟内存大小
- free: 空闲物理内存大小
- buff: 用作缓冲的内存大小(内存和硬盘的缓冲区)
- cache: 用作缓存的内存大小(CPU和内存之间的缓冲区)
- si: 每秒从交换区写到内存的大小,由磁盘调入内存
- so: 每秒写入交换区的内存大小,由内存调入磁盘
- bi: 每秒读取的块数
- bo: 每秒写入的块数
- in: 每秒中断数,包括时钟中断。
- cs: 每秒上下文切换数。
- us: 用户进程执行时间百分比(user time)
- sy: 内核系统进程执行时间百分比(system time)
- wa: IO等待时间百分比
- id: 空闲时间百分比
pidstat命令
pidstat 是 Sysstat 中的一个组件,也是一款功能强大的性能监测工具,用于监控全部或指定进程的cpu、内存、线程、设备IO等系统资源的占用情况。 pidstat首次运行时显示自系统启动开始的各项统计信息,之后运行pidstat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。 top 和 vmstat 两个命令都是监测进程的内存、CPU 以及 I/O 使用情况,而 pidstat 命令可以检测到线程级别的。 用法:pidstat [ options ] [ <interval> [ <count> ] ] 实例:查看进程的线程上下文切换情况 pidstat命令线程切换字段说明如下:
- UID :被监控任务的真实用户ID。
- TGID :线程组ID。
- TID:线程ID。
- cswch/s:主动切换上下文次数,这里是因为资源阻塞而切换线程,比如锁等待等情况。
- nvcswch/s:被动切换上下文次数,这里指CPU调度切换了线程。
二、JDK状态查看工具
Java应用通过docker部署时,需要先进入docker容器,下面以查看网关服务应用的JVM进程为例 1.查看正在运行的容器 docker ps -a 2.进入Java应用的容器 docker exec -it 841df152da3f /bin/bash 图中iftp-gateway-1.0.0-SNAPSHOT.jar运行的JVM进程ID是1
jps命令
jps(JVM Process Status)类似 UNIX 的 ps 命令。用来查看所有 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息; 用法: jps [-q] [-mlvV] [<hostid>] [-help] 实例: jps:显示虚拟机执行主类名称以及这些进程的本地虚拟机唯一 ID(Local Virtual Machine Identifier,LVMID)。 jps -q :只输出进程的本地虚拟机唯一 ID。 jps -l:输出主类的全名,如果进程执行的是 Jar 包,输出 Jar 路径。 jps -v:输出虚拟机进程启动时 JVM 参数。 jps -m:输出传递给 Java 进程 main() 函数的参数。
jinfo命令
jinfo(Configuration Info for Java)用来查看和修改虚拟机配置信息;使用 jinfo 可以在不重启虚拟机的情况下,可以动态的修改 jvm 的参数,尤其在线上的环境特别有用。 用法: jinfo [option] <pid> (to connect to running process) jinfo [option] <executable <core> (to connect to a core file) jinfo [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: -flag <name> to print the value of the named VM flag -flag [+|-]<name> to enable or disable the named VM flag -flag <name>=<value> to set the named VM flag to the given value -flags to print VM flags -sysprops to print Java system properties <no option> to print both of the above -h | -help to print this help message jinfo pid :输出当前 jvm 进程的全部参数和系统属性 (第一部分是系统的属性,第二部分是 JVM 的参数)。 jinfo -flag name pid :输出对应名称的参数的具体值。比如输出 MaxHeapSize、查看当前 jvm 进程是否开启打印 GC 日志 ( -XX:PrintGCDetails :详细 GC 日志模式,这两个都是默认关闭的)。 实例:查看指定java进程的虚拟机配置信息 jinfo -flags 4484
注意: 新版的Linux系统和docker容器加入了 ptrace-scope 机制,该机制的目的是防止用户访问正在执行的进程的内存,但是如jinfo,jmap这些调试类工具本身就是利用ptrace来获取执行进程的内存等信息, 需要开放对应权限。如果出现以下报错,需要开放对应的安全限制。
jstat 命令
jstat -gc -h3 1 1000 10
表示分析进程 id 为 31736 的 gc 情况,每隔 1000ms 打印一次记录,打印 10 次停止,每 3 行后打印指标头部。 常用的命令是jstat -gc pid 信息字段说明如下:
- S0C:年轻代中 To Survivor 的容量(单位 KB);
- S1C:年轻代中 From Survivor 的容量(单位 KB);
- S0U:年轻代中 To Survivor 目前已使用空间(单位 KB);
- S1U:年轻代中 From Survivor 目前已使用空间(单位 KB);
- EC:年轻代中 Eden 的容量(单位 KB);
- EU:年轻代中 Eden 目前已使用空间(单位 KB);
- OC:老年代的容量(单位 KB);
- OU:老年代目前已使用空间(单位 KB);
- MC:元空间的容量(单位 KB);
- MU:元空间目前已使用空间(单位 KB);
- YGC:从应用程序启动到采样时年轻代中 gc 次数;
- YGCT:从应用程序启动到采样时年轻代中 gc 所用时间 (s);
- FGC:从应用程序启动到采样时 老年代(Full Gc)gc 次数;
- FGCT:从应用程序启动到采样时 老年代代(Full Gc)gc 所用时间 (s);
- GCT:从应用程序启动到采样时 gc 用的总时间 (s)。
jmap命令
jmap(Memory Map for Java)也是JDK工具命令,可以查看堆内存的初始化信息以及堆内存的使用情况,finalizer 执行队列,还可以生成堆转储快照的dump文件来进行详细分析。 用法: 查看堆内存情况命令jmap -heap pid 将指定应用程序的堆快照输出到指定目录 jmap -dump:format=b,file=/opt/iftp-gateway-heap.hprof 1 JVM堆内存导出文件分析 MAT内存工具 MAT(Memory Analyzer Tool)工具是eclipse的一个插件(MAT也可以单独使用),它分析大内存的dump文件时,可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询, 以及可以很方便的找出对象GC Roots的相关信息。 商业版的堆转存文件分析工具可以使用JProfiler;
jstack命令
jstack(Stack Trace for Java)是JDK工具命令,它是一种线程堆栈分析工具,最常用的功能就是使用 jstack pid 命令查看线程的堆栈信息,也经常用来排除死锁情况。
用法:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)
jstack [-m] [-l] <executable> <core>
(to connect to a core file)
jstack [-m] [-l] [server_id@]<remote server IP or hostname>
(to connect to a remote debug server)
参数:
-F to force a thread dump. Use when jstack <pid> does not respond (process is hung)
-m to print both java and native frames (mixed mode)
-l long listing. Prints additional information about locks
-h or -help to print this help message
模拟环境准备
基础环境jdk1.8,采用SpringBoot框架来写几个接口来触发模拟场景,首先是模拟CPU占满情况
CPU占满 模拟CPU占满还是比较简单,直接写一个死循环计算消耗CPU即可。
/**
* 模拟CPU占满
*/
@GetMapping("/cpu/loop")
public void testCPULoop() throws InterruptedException {
System.out.println("请求cpu死循环");
Thread.currentThread().setName("loop-thread-cpu");
int num = 0;
while (true) {
num++;
if (num == Integer.MAX_VALUE) {
System.out.println("reset");
}
num = 0;
}
}
请求接口地址测试curl localhost:8080/cpu/loop,发现CPU立马飙升到100% 通过执行top -Hp 32805 查看Java线程情况 执行 printf '%x' 32826 获取16进制的线程id,用于堆栈信息查询,结果为 803a。最后我们执行jstack 32805 |grep -A 20 803a来查看下详细的dump信息。 这里堆栈信息直接定位出了问题方法以及代码行,这就定位出了CPU占满的问题。 内存泄露 模拟内存泄漏借助了ThreadLocal对象来完成,ThreadLocal是一个线程私有变量,可以绑定到线程上,在整个线程的生命周期都会存在,但是由于ThreadLocal的特殊性, ThreadLocal是基于ThreadLocalMap实现的,ThreadLocalMap的Entry继承WeakReference,而Entry的Key是WeakReference的封装,换句话说Key就是弱引用,弱引用在下次GC之后就会被回收, 如果ThreadLocal在set之后不进行后续的操作,因为GC会把Key清除掉,但是Value由于线程还在存活,所以Value一直不会被回收,最后就会发生内存泄漏。
/**
* 模拟内存泄漏
*/
@GetMapping(value = "/memory/leak")
public String leak() {
System.out.println("模拟内存泄漏");
ThreadLocal<Byte[]> localVariable = new ThreadLocal<Byte[]>();
localVariable.set(new Byte[4096 * 1024]);// 为线程添加变量
return "ok";
}
我们给启动加上堆内存大小限制,同时设置内存溢出的时候输出堆栈快照并输出日志。 java -jar -Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heaplog.log analysis-demo-0.0.1-SNAPSHOT.jar 启动成功后我们循环执行100次,for i in {1..500}; do curl localhost:8080/memory/leak;done,还没执行完毕,系统已经返回500错误了。查看系统日志出现了如下异常:
java.lang.OutOfMemoryError: Java heap space
我们用jstat -gc pid 命令来看看程序的GC情况。 很明显,内存溢出了,堆内存经过45次 Full Gc 之后都没释放出可用内存,这说明当前堆内存中的对象都是存活的,有GC Roots引用,无法回收。那是什么原因导致内存溢出呢?是不是我只要加大内存就行了呢? 如果是普通的内存溢出也许扩大内存就行了,但是如果是内存泄漏的话,扩大的内存不一会就会被占满,所以我们还需要确定是不是内存泄漏。 我们之前保存了堆 Dump 文件,这个时候借助我们的MAT工具来分析下。导入工具选择Leak Suspects Report,工具直接就会给你列出问题报告。
这里已经列出了可疑的4个内存泄漏问题,我们点击其中一个查看详情。 这里已经指出了内存被线程占用了接近50M的内存,占用的对象就是ThreadLocal。如果想详细的通过手动去分析的话,可以点击Histogram,查看最大的对象占用是谁,然后再分析它的引用关系,即可确定是谁导致的内存溢出。 上图发现占用内存最大的对象是一个Byte数组,我们看看它到底被那个GC Root引用导致没有被回收。按照上图红框操作指引,结果如下图: 我们发现Byte数组是被线程对象引用的,图中也标明,Byte数组对像的GC Root是线程,所以它是不会被回收的,展开详细信息查看,我们发现最终的内存占用对象是被ThreadLocal对象占据了。 这也和MAT工具自动帮我们分析的结果一致。 死锁 死锁会导致耗尽线程资源,占用内存,表现就是内存占用升高,CPU不一定会飙升(看场景决定),如果是直接new线程,会导致JVM内存被耗尽,报无法创建线程的错误,这也是体现了使用线程池的好处。
ExecutorService service = new ThreadPoolExecutor(4, 10,
0, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(1024),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
/**
* 模拟死锁
*/
@GetMapping("/cpu/test")
public String testCPU() throws InterruptedException {
System.out.println("请求cpu");
Object lock1 = new Object();
Object lock2 = new Object();
service.submit(new DeadLockThread(lock1, lock2), "deadLookThread-" + new Random().nextInt());
service.submit(new DeadLockThread(lock2, lock1), "deadLookThread-" + new Random().nextInt());
return "ok";
}
public class DeadLockThread implements Runnable {
private Object lock1;
private Object lock2;
public DeadLockThread1(Object lock1, Object lock2) {
this.lock1 = lock1;
this.lock2 = lock2;
}
@Override
public void run() {
synchronized (lock2) {
System.out.println(Thread.currentThread().getName()+"get lock2 and wait lock1");
try {
TimeUnit.MILLISECONDS.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock1) {
System.out.println(Thread.currentThread().getName()+"get lock1 and lock2 ");
}
}
}
}
我们循环请求接口2000次,发现不一会系统就出现了日志错误,线程池和队列都满了,由于我选择的当队列满了就拒绝的策略,所以系统直接抛出异常。 java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@2760298 rejected from java.util.concurrent.ThreadPoolExecutor@7ea7cd51[Running, pool size = 10, active threads = 10, queued tasks = 1024, completed tasks = 846] 通过ps -ef|grep java命令找出 Java 进程 pid,执行jstack pid 即可出现java线程堆栈信息,这里发现了5个死锁,我们只列出其中一个, 很明显线程pool-1-thread-2锁住了0x00000000f8387d88等待0x00000000f8387d98锁,线程pool-1-thread-1锁住了0x00000000f8387d98等待锁0x00000000f8387d88,这就产生了死锁。
Java stack information for the threads listed above:
===================================================
"pool-1-thread-2":
at top.luozhou.analysisdemo.controller.DeadLockThread2.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d98> (a java.lang.Object)
- locked <0x00000000f8387d88> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-1":
at top.luozhou.analysisdemo.controller.DeadLockThread1.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d88> (a java.lang.Object)
- locked <0x00000000f8387d98> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Found 5 deadlocks.
线程频繁切换 上下文切换会导致将大量CPU时间浪费在寄存器、内核栈以及虚拟内存的保存和恢复上,导致系统整体性能下降。当你发现系统的性能出现明显的下降时候,需要考虑是否发生了大量的线程上下文切换。
@GetMapping(value = "/thread/swap")
public String theadSwap(int num) {
System.out.println("模拟线程切换");
for (int i = 0; i < num; i++) {
new Thread(new ThreadSwap1(new AtomicInteger(0)),"thread-swap"+i).start();
}
return "ok";
}
public class ThreadSwap1 implements Runnable {
private AtomicInteger integer;
public ThreadSwap1(AtomicInteger integer) {
this.integer = integer;
}
@Override
public void run() {
while (true) {
integer.addAndGet(1);
Thread.yield(); //让出CPU资源
}
}
}
这里我创建多个线程去执行基础的原子+1操作,然后让出 CPU 资源,理论上 CPU 就会去调度别的线程, 我们请求接口创建100个线程看看效果如何,curl localhost:8080/thread/swap?num=100。 接口请求成功后,我们执行`vmstat 1 10,表示每1秒打印一次,打印10次,线程切换采集结果如下:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
101 0 128000 878384 908 468684 0 0 0 0 4071 8110498 14 86 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4065 8312463 15 85 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4107 8207718 14 87 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4083 8410174 14 86 0 0 0
100 0 128000 878384 908 468684 0 0 0 0 4083 8264377 14 86 0 0 0
100 0 128000 878384 908 468688 0 0 0 108 4182 8346826 14 86 0 0 0
这里我们关注4个指标,r,cs,us,sy。 r=100,说明等待的进程数量是100,线程有阻塞。 cs=800多万,说明每秒上下文切换了800多万次,这个数字相当大了。 us=14,说明用户态占用了14%的CPU时间片去处理逻辑。 sy=86,说明内核态占用了86%的CPU,这里明显就是做上下文切换工作了。 我们通过top命令以及top -Hp pid查看进程和线程CPU情况,发现Java线程CPU占满了,但是线程CPU使用情况很平均,没有某一个线程把CPU吃满的情况。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87093 root 20 0 4194788 299056 13252 S 399.7 16.1 65:34.67 java
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87189 root 20 0 4194788 299056 13252 R 4.7 16.1 0:41.11 java
87129 root 20 0 4194788 299056 13252 R 4.3 16.1 0:41.14 java
87130 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.51 java
87133 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.59 java
87134 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.95 java
结合上面用户态CPU只使用了14%,内核态CPU占用了86%,可以基本判断是Java程序线程上下文切换导致性能问题。 我们使用pidstat命令来看看Java进程内部的线程切换数据,执行pidstat -p 87093 -w 1 10,采集数据如下:
11:04:30 PM UID TGID TID cswch/s nvcswch/s Command
11:04:30 PM 0 - 87128 0.00 16.07 |__java
11:04:30 PM 0 - 87129 0.00 15.60 |__java
11:04:30 PM 0 - 87130 0.00 15.54 |__java
11:04:30 PM 0 - 87131 0.00 15.60 |__java
11:04:30 PM 0 - 87132 0.00 15.43 |__java
11:04:30 PM 0 - 87133 0.00 16.02 |__java
11:04:30 PM 0 - 87134 0.00 15.66 |__java
11:04:30 PM 0 - 87135 0.00 15.23 |__java
11:04:30 PM 0 - 87136 0.00 15.33 |__java
11:04:30 PM 0 - 87137 0.00 16.04 |__java
根据上面采集的信息,我们知道Java的线程每秒切换15次左右,正常情况下,应该是个位数或者小数。结合这些信息我们可以断定Java线程开启过多,导致频繁上下文切换,从而影响了整体性能。 为什么系统的上下文切换是每秒800多万,而 Java 进程中的某一个线程切换才15次左右? 系统上下文切换分为三种情况: 1、多任务:在多任务环境中,一个进程被切换出CPU,运行另外一个进程,这里会发生上下文切换。 2、中断处理:发生中断时,硬件会切换上下文。在vmstat命令中是in 3、用户和内核模式切换:当操作系统中需要在用户模式和内核模式之间进行转换时,需要进行上下文切换,比如进行系统函数调用。 Linux 为每个 CPU 维护了一个就绪队列,将活跃进程按照优先级和等待 CPU 的时间排序,然后选择最需要 CPU 的进程,也就是优先级最高和等待 CPU 时间最长的进程来运行。也就是vmstat命令中的r。 那么,进程在什么时候才会被调度到 CPU 上运行呢? • 进程执行完终止了,它之前使用的 CPU 会释放出来,这时再从就绪队列中拿一个新的进程来运行 • 为了保证所有进程可以得到公平调度,CPU 时间被划分为一段段的时间片,这些时间片被轮流分配给各个进程。当某个进程时间片耗尽了就会被系统挂起,切换到其它等待 CPU 的进程运行。 • 进程在系统资源不足时,要等待资源满足后才可以运行,这时进程也会被挂起,并由系统调度其它进程运行。 • 当进程通过睡眠函数 sleep 主动挂起时,也会重新调度。 • 当有优先级更高的进程运行时,为了保证高优先级进程的运行,当前进程会被挂起,由高优先级进程来运行。 • 发生硬件中断时,CPU 上的进程会被中断挂起,转而执行内核中的中断服务程序。 结合我们之前的内容分析,阻塞的就绪队列是100左右,而我们的CPU只有4核,这部分原因造成的上下文切换就可能会相当高,再加上中断次数是4000左右和系统的函数调用等,整个系统的上下文切换到800万也不足为奇了。 Java内部的线程切换才15次,是因为线程使用Thread.yield()来让出CPU资源,但是CPU有可能继续调度该线程,这个时候线程之间并没有切换,这也是为什么内部的某个线程切换次数并不是非常大的原因。