概述
性能優(yōu)化一向是后端服務(wù)優(yōu)化的重點(diǎn)杯聚，但是線上性能故障問題不是經(jīng)常出現(xiàn)，或者受限于業(yè)務(wù)產(chǎn)品抒痒，根本就沒辦法出現(xiàn)性能問題幌绍，包括筆者自己遇到的性能問題也不多，所以為了提前儲(chǔ)備知識(shí)故响，當(dāng)出現(xiàn)問題的時(shí)候不會(huì)手忙腳亂傀广，我們本篇文章來模擬下常見的幾個(gè) Java 性能故障，來學(xué)習(xí)怎么去分析和定位彩届。
預(yù)備知識(shí)
既然是定位問題伪冰，肯定是需要借助工具，我們先了解下需要哪些工具可以幫忙定位問題樟蠕。
top 命令
top命令使我們最常用的 Linux 命令之一贮聂，它可以實(shí)時(shí)的顯示當(dāng)前正在執(zhí)行的進(jìn)程的 CPU 使用率靠柑，內(nèi)存使用率等系統(tǒng)信息。top -Hp pid 可以查看線程的系統(tǒng)資源使用情況吓懈。
vmstat 命令
vmstat 是一個(gè)指定周期和采集次數(shù)的虛擬內(nèi)存檢測(cè)工具歼冰，可以統(tǒng)計(jì)內(nèi)存，CPU耻警，swap 的使用情況隔嫡，它還有一個(gè)重要的常用功能，用來觀察進(jìn)程的上下文切換甘穿。字段說明如下:
r: 運(yùn)行隊(duì)列中進(jìn)程數(shù)量（當(dāng)數(shù)量大于 CPU 核數(shù)表示有阻塞的線程）
b: 等待 IO 的進(jìn)程數(shù)量
swpd: 使用虛擬內(nèi)存大小
free: 空閑物理內(nèi)存大小
buff: 用作緩沖的內(nèi)存大小(內(nèi)存和硬盤的緩沖區(qū))
cache: 用作緩存的內(nèi)存大腥鳌（CPU 和內(nèi)存之間的緩沖區(qū)）
si: 每秒從交換區(qū)寫到內(nèi)存的大小，由磁盤調(diào)入內(nèi)存
so: 每秒寫入交換區(qū)的內(nèi)存大小温兼，由內(nèi)存調(diào)入磁盤
bi: 每秒讀取的塊數(shù)
bo: 每秒寫入的塊數(shù)
in: 每秒中斷數(shù)庆揪，包括時(shí)鐘中斷。
cs: 每秒上下文切換數(shù)妨托。
us: 用戶進(jìn)程執(zhí)行時(shí)間百分比(user time)
sy: 內(nèi)核系統(tǒng)進(jìn)程執(zhí)行時(shí)間百分比(system time)
wa: IO 等待時(shí)間百分比
id: 空閑時(shí)間百分比
pidstat 命令
pidstat 是 Sysstat 中的一個(gè)組件，也是一款功能強(qiáng)大的性能監(jiān)測(cè)工具吝羞，top 和 vmstat 兩個(gè)命令都是監(jiān)測(cè)進(jìn)程的內(nèi)存兰伤、CPU 以及 I/O 使用情況钧排，而 pidstat 命令可以檢測(cè)到線程級(jí)別的敦腔。pidstat命令線程切換字段說明如下：
UID ：被監(jiān)控任務(wù)的真實(shí)用戶 ID。
TGID ：線程組 ID恨溜。
TID：線程 ID符衔。
cswch/s：主動(dòng)切換上下文次數(shù)，這里是因?yàn)橘Y源阻塞而切換線程糟袁，比如鎖等待等情況判族。
nvcswch/s：被動(dòng)切換上下文次數(shù)，這里指 CPU 調(diào)度切換了線程项戴。
jstack 命令
jstack 是 JDK 工具命令形帮，它是一種線程堆棧分析工具，最常用的功能就是使用 jstack pid 命令查看線程的堆棧信息周叮，也經(jīng)常用來排除死鎖情況辩撑。
jstat 命令
它可以檢測(cè) Java 程序運(yùn)行的實(shí)時(shí)情況，包括堆內(nèi)存信息和垃圾回收信息仿耽，我們常常用來查看程序垃圾回收情況合冀。常用的命令是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：從應(yīng)用程序啟動(dòng)到采樣時(shí)年輕代中 gc 次數(shù)砌滞；
YGCT：從應(yīng)用程序啟動(dòng)到采樣時(shí)年輕代中 gc 所用時(shí)間 (s)侮邀；
FGC：從應(yīng)用程序啟動(dòng)到采樣時(shí) 老年代（Full Gc）gc 次數(shù)；
FGCT：從應(yīng)用程序啟動(dòng)到采樣時(shí) 老年代代（Full Gc）gc 所用時(shí)間 (s)贝润；
GCT：從應(yīng)用程序啟動(dòng)到采樣時(shí) gc 用的總時(shí)間 (s)绊茧。
jmap 命令
jmap 也是 JDK 工具命令，他可以查看堆內(nèi)存的初始化信息以及堆內(nèi)存的使用情況打掘，還可以生成 dump 文件來進(jìn)行詳細(xì)分析华畏。查看堆內(nèi)存情況命令jmap -heap pid。
mat 內(nèi)存工具
MAT(Memory Analyzer Tool)工具是 eclipse 的一個(gè)插件(MAT 也可以單獨(dú)使用)尊蚁，它分析大內(nèi)存的 dump 文件時(shí)亡笑，可以非常直觀的看到各個(gè)對(duì)象在堆空間中所占用的內(nèi)存大小、類實(shí)例數(shù)量横朋、對(duì)象引用關(guān)系仑乌、利用 OQL 對(duì)象查詢，以及可以很方便的找出對(duì)象 GC Roots 的相關(guān)信息琴锭。
idea 中也有這么一個(gè)插件晰甚，就是 JProfiler。
相關(guān)閱讀：《性能診斷利器 JProfiler 快速入門和最佳實(shí)踐》(opens new window)
模擬環(huán)境準(zhǔn)備
基礎(chǔ)環(huán)境 jdk1.8决帖，采用 SpringBoot 框架來寫幾個(gè)接口來觸發(fā)模擬場(chǎng)景厕九，首先是模擬 CPU 占滿情況
CPU 占滿
模擬 CPU 占滿還是比較簡(jiǎn)單，直接寫一個(gè)死循環(huán)計(jì)算消耗 CPU 即可地回。
/**
* 模擬CPU占滿
*/
@GetMapping("/cpu/loop")
public void testCPULoop() throws InterruptedException {
System.out.println("請(qǐng)求cpu死循環(huán)");
Thread.currentThread().setName("loop-thread-cpu");
int num = 0;
while (true) {
num++;
if (num == Integer.MAX_VALUE) {
System.out.println("reset");
}
num = 0;
}
}
請(qǐng)求接口地址測(cè)試curl localhost:8080/cpu/loop,發(fā)現(xiàn) CPU 立馬飆升到 100%
通過執(zhí)行top -Hp 32805 查看 Java 線程情況
執(zhí)行 printf '%x' 32826 獲取 16 進(jìn)制的線程 id止剖，用于dump信息查詢，結(jié)果為 803a落君。最后我們執(zhí)行jstack 32805 |grep -A 20 803a來查看下詳細(xì)的dump信息穿香。
這里dump信息直接定位出了問題方法以及代碼行，這就定位出了 CPU 占滿的問題绎速。
內(nèi)存泄露
模擬內(nèi)存泄漏借助了 ThreadLocal 對(duì)象來完成皮获，ThreadLocal 是一個(gè)線程私有變量，可以綁定到線程上纹冤，在整個(gè)線程的生命周期都會(huì)存在洒宝，但是由于 ThreadLocal 的特殊性购公，ThreadLocal 是基于 ThreadLocalMap 實(shí)現(xiàn)的，ThreadLocalMap 的 Entry 繼承 WeakReference雁歌，而 Entry 的 Key 是 WeakReference 的封裝宏浩，換句話說 Key 就是弱引用，弱引用在下次 GC 之后就會(huì)被回收靠瞎，如果 ThreadLocal 在 set 之后不進(jìn)行后續(xù)的操作比庄，因?yàn)?GC 會(huì)把 Key 清除掉，但是 Value 由于線程還在存活乏盐，所以 Value 一直不會(huì)被回收佳窑，最后就會(huì)發(fā)生內(nèi)存泄漏。
/**
* 模擬內(nèi)存泄漏
*/
@GetMapping(value = "/memory/leak")
public String leak() {
System.out.println("模擬內(nèi)存泄漏");
ThreadLocal<Byte[]> localVariable = new ThreadLocal<Byte[]>();
localVariable.set(new Byte[4096 * 1024]);// 為線程添加變量
return "ok";
}
我們給啟動(dòng)加上堆內(nèi)存大小限制父能，同時(shí)設(shè)置內(nèi)存溢出的時(shí)候輸出堆椛翊眨快照并輸出日志。
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
啟動(dòng)成功后我們循環(huán)執(zhí)行 100 次,for i in {1..500}; do curl localhost:8080/memory/leak;done,還沒執(zhí)行完畢何吝，系統(tǒng)已經(jīng)返回 500 錯(cuò)誤了溉委。查看系統(tǒng)日志出現(xiàn)了如下異常：
java.lang.OutOfMemoryError: Java heap space
我們用jstat -gc pid 命令來看看程序的 GC 情況。
很明顯爱榕，內(nèi)存溢出了瓣喊，堆內(nèi)存經(jīng)過 45 次 Full Gc 之后都沒釋放出可用內(nèi)存，這說明當(dāng)前堆內(nèi)存中的對(duì)象都是存活的呆细，有 GC Roots 引用，無法回收八匠。那是什么原因?qū)е聝?nèi)存溢出呢絮爷？是不是我只要加大內(nèi)存就行了呢？如果是普通的內(nèi)存溢出也許擴(kuò)大內(nèi)存就行了梨树，但是如果是內(nèi)存泄漏的話坑夯，擴(kuò)大的內(nèi)存不一會(huì)就會(huì)被占滿，所以我們還需要確定是不是內(nèi)存泄漏抡四。我們之前保存了堆 Dump 文件柜蜈，這個(gè)時(shí)候借助我們的 MAT 工具來分析下。導(dǎo)入工具選擇Leak Suspects Report指巡，工具直接就會(huì)給你列出問題報(bào)告淑履。
這里已經(jīng)列出了可疑的 4 個(gè)內(nèi)存泄漏問題，我們點(diǎn)擊其中一個(gè)查看詳情藻雪。
這里已經(jīng)指出了內(nèi)存被線程占用了接近 50M 的內(nèi)存秘噪，占用的對(duì)象就是 ThreadLocal。如果想詳細(xì)的通過手動(dòng)去分析的話勉耀，可以點(diǎn)擊Histogram,查看最大的對(duì)象占用是誰(shuí)指煎，然后再分析它的引用關(guān)系蹋偏，即可確定是誰(shuí)導(dǎo)致的內(nèi)存溢出。
上圖發(fā)現(xiàn)占用內(nèi)存最大的對(duì)象是一個(gè) Byte 數(shù)組至壤，我們看看它到底被那個(gè) GC Root 引用導(dǎo)致沒有被回收威始。按照上圖紅框操作指引，結(jié)果如下圖：
我們發(fā)現(xiàn) Byte 數(shù)組是被線程對(duì)象引用的像街，圖中也標(biāo)明黎棠，Byte 數(shù)組對(duì)像的 GC Root 是線程，所以它是不會(huì)被回收的宅广，展開詳細(xì)信息查看葫掉，我們發(fā)現(xiàn)最終的內(nèi)存占用對(duì)象是被 ThreadLocal 對(duì)象占據(jù)了。這也和 MAT 工具自動(dòng)幫我們分析的結(jié)果一致跟狱。
死鎖
死鎖會(huì)導(dǎo)致耗盡線程資源俭厚，占用內(nèi)存，表現(xiàn)就是內(nèi)存占用升高驶臊，CPU 不一定會(huì)飆升(看場(chǎng)景決定)挪挤，如果是直接 new 線程，會(huì)導(dǎo)致 JVM 內(nèi)存被耗盡关翎，報(bào)無法創(chuàng)建線程的錯(cuò)誤扛门，這也是體現(xiàn)了使用線程池的好處。
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("請(qǐng)求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 ");
}
}
}
}
我們循環(huán)請(qǐng)求接口 2000 次纵寝，發(fā)現(xiàn)不一會(huì)系統(tǒng)就出現(xiàn)了日志錯(cuò)誤论寨，線程池和隊(duì)列都滿了,由于我選擇的當(dāng)隊(duì)列滿了就拒絕的策略，所以系統(tǒng)直接拋出異常爽茴。
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 進(jìn)程 pid葬凳，執(zhí)行jstack pid 即可出現(xiàn) java 線程堆棧信息，這里發(fā)現(xiàn)了 5 個(gè)死鎖室奏，我們只列出其中一個(gè)火焰，很明顯線程pool-1-thread-2鎖住了0x00000000f8387d88等待0x00000000f8387d98鎖，線程pool-1-thread-1鎖住了0x00000000f8387d98等待鎖0x00000000f8387d88,這就產(chǎn)生了死鎖胧沫。
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.
線程頻繁切換
上下文切換會(huì)導(dǎo)致將大量 CPU 時(shí)間浪費(fèi)在寄存器昌简、內(nèi)核棧以及虛擬內(nèi)存的保存和恢復(fù)上，導(dǎo)致系統(tǒng)整體性能下降绒怨。當(dāng)你發(fā)現(xiàn)系統(tǒng)的性能出現(xiàn)明顯的下降時(shí)候纯赎，需要考慮是否發(fā)生了大量的線程上下文切換。
@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資源
}
}
}
這里我創(chuàng)建多個(gè)線程去執(zhí)行基礎(chǔ)的原子+1 操作南蹂，然后讓出 CPU 資源址否，理論上 CPU 就會(huì)去調(diào)度別的線程，我們請(qǐng)求接口創(chuàng)建 100 個(gè)線程看看效果如何，curl localhost:8080/thread/swap?num=100佑附。接口請(qǐng)求成功后樊诺，我們執(zhí)行 vmstat 1 10，表示每 1 秒打印一次音同，打印 10 次词爬，線程切換采集結(jié)果如下：
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
這里我們關(guān)注 4 個(gè)指標(biāo)，r,cs,us,sy权均。
r=100,說明等待的進(jìn)程數(shù)量是 100顿膨，線程有阻塞酌予。
cs=800 多萬(wàn)檬果，說明每秒上下文切換了 800 多萬(wàn)次拄轻，這個(gè)數(shù)字相當(dāng)大了喂击。
us=14，說明用戶態(tài)占用了 14%的 CPU 時(shí)間片去處理邏輯萤厅。
sy=86入录，說明內(nèi)核態(tài)占用了 86%的 CPU来涨，這里明顯就是做上下文切換工作了塔橡。
我們通過top命令以及top -Hp pid查看進(jìn)程和線程 CPU 情況梅割，發(fā)現(xiàn) Java 進(jìn)程 CPU 占滿了，但是線程 CPU 使用情況很平均葛家，沒有某一個(gè)線程把 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
結(jié)合上面用戶態(tài) CPU 只使用了 14%，內(nèi)核態(tài) CPU 占用了 86%癞谒，可以基本判斷是 Java 程序線程上下文切換導(dǎo)致性能問題底燎。
我們使用pidstat命令來看看 Java 進(jìn)程內(nèi)部的線程切換數(shù)據(jù)，執(zhí)行pidstat -p 87093 -w 1 10,采集數(shù)據(jù)如下：
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
根據(jù)上面采集的信息弹砚，我們知道 Java 的線程每秒切換 15 次左右双仍，正常情況下，應(yīng)該是個(gè)位數(shù)或者小數(shù)迅栅。結(jié)合這些信息我們可以斷定 Java 線程開啟過多殊校，導(dǎo)致頻繁上下文切換晴玖，從而影響了整體性能读存。
為什么系統(tǒng)的上下文切換是每秒 800 多萬(wàn)，而 Java 進(jìn)程中的某一個(gè)線程切換才 15 次左右呕屎？
系統(tǒng)上下文切換分為三種情況:
1让簿、多任務(wù)：在多任務(wù)環(huán)境中，一個(gè)進(jìn)程被切換出 CPU秀睛，運(yùn)行另外一個(gè)進(jìn)程尔当，這里會(huì)發(fā)生上下文切換。
2、中斷處理：發(fā)生中斷時(shí)椭迎，硬件會(huì)切換上下文锐帜。在 vmstat 命令中是in
3、用戶和內(nèi)核模式切換：當(dāng)操作系統(tǒng)中需要在用戶模式和內(nèi)核模式之間進(jìn)行轉(zhuǎn)換時(shí)畜号，需要進(jìn)行上下文切換,比如進(jìn)行系統(tǒng)函數(shù)調(diào)用缴阎。
Linux 為每個(gè) CPU 維護(hù)了一個(gè)就緒隊(duì)列，將活躍進(jìn)程按照優(yōu)先級(jí)和等待 CPU 的時(shí)間排序简软，然后選擇最需要 CPU 的進(jìn)程蛮拔，也就是優(yōu)先級(jí)最高和等待 CPU 時(shí)間最長(zhǎng)的進(jìn)程來運(yùn)行。也就是 vmstat 命令中的r痹升。
那么建炫，進(jìn)程在什么時(shí)候才會(huì)被調(diào)度到 CPU 上運(yùn)行呢？
- 進(jìn)程執(zhí)行完終止了疼蛾，它之前使用的 CPU 會(huì)釋放出來肛跌，這時(shí)再?gòu)木途w隊(duì)列中拿一個(gè)新的進(jìn)程來運(yùn)行
- 為了保證所有進(jìn)程可以得到公平調(diào)度，CPU 時(shí)間被劃分為一段段的時(shí)間片据过，這些時(shí)間片被輪流分配給各個(gè)進(jìn)程惋砂。當(dāng)某個(gè)進(jìn)程時(shí)間片耗盡了就會(huì)被系統(tǒng)掛起，切換到其它等待 CPU 的進(jìn)程運(yùn)行绳锅。
- 進(jìn)程在系統(tǒng)資源不足時(shí)西饵，要等待資源滿足后才可以運(yùn)行，這時(shí)進(jìn)程也會(huì)被掛起鳞芙，并由系統(tǒng)調(diào)度其它進(jìn)程運(yùn)行眷柔。
- 當(dāng)進(jìn)程通過睡眠函數(shù) sleep 主動(dòng)掛起時(shí)，也會(huì)重新調(diào)度原朝。
- 當(dāng)有優(yōu)先級(jí)更高的進(jìn)程運(yùn)行時(shí)驯嘱，為了保證高優(yōu)先級(jí)進(jìn)程的運(yùn)行，當(dāng)前進(jìn)程會(huì)被掛起喳坠，由高優(yōu)先級(jí)進(jìn)程來運(yùn)行鞠评。
- 發(fā)生硬件中斷時(shí)，CPU 上的進(jìn)程會(huì)被中斷掛起壕鹉，轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務(wù)程序剃幌。
結(jié)合我們之前的內(nèi)容分析，阻塞的就緒隊(duì)列是 100 左右晾浴，而我們的 CPU 只有 4 核负乡，這部分原因造成的上下文切換就可能會(huì)相當(dāng)高，再加上中斷次數(shù)是 4000 左右和系統(tǒng)的函數(shù)調(diào)用等脊凰，整個(gè)系統(tǒng)的上下文切換到 800 萬(wàn)也不足為奇了抖棘。Java 內(nèi)部的線程切換才 15 次，是因?yàn)榫€程使用Thread.yield()來讓出 CPU 資源，但是 CPU 有可能繼續(xù)調(diào)度該線程切省，這個(gè)時(shí)候線程之間并沒有切換最岗，這也是為什么內(nèi)部的某個(gè)線程切換次數(shù)并不是非常大的原因。
總結(jié)
本文模擬了常見的性能問題場(chǎng)景朝捆，分析了如何定位 CPU100%仑性、內(nèi)存泄漏、死鎖右蹦、線程頻繁切換問題诊杆。分析問題我們需要做好兩件事，第一何陆，掌握基本的原理晨汹，第二，借助好工具贷盲。本文也列舉了分析問題的常用工具和命令淘这，希望對(duì)你解決問題有所幫助。當(dāng)然真正的線上環(huán)境可能十分復(fù)雜巩剖，并沒有模擬的環(huán)境那么簡(jiǎn)單铝穷，但是原理是一樣的，問題的表現(xiàn)也是類似的佳魔，我們重點(diǎn)抓住原理曙聂，活學(xué)活用，相信復(fù)雜的線上問題也可以順利解決鞠鲜。
