幾年前的一個(gè)下午，公司里碼農(nóng)們正在安靜地敲著代碼，突然很多人的手機(jī)同時(shí)“嗶嗶”地響了起來。本來以為發(fā)工資了，都挺高興！打開一看，原來是告警短信

故障回顧

告警提示“線程數(shù)過多，超出閾值”，“CPU空閑率太低”。打開監(jiān)控系統(tǒng)一看，訂單服務(wù)所有20個(gè)服務(wù)節(jié)點(diǎn)都不行了，服務(wù)沒響應(yīng)。

到聽云（一個(gè)全鏈路性能監(jiān)控工具）上看監(jiān)控，每個(gè)springboot節(jié)點(diǎn)線程數(shù)全都達(dá)到了最大值。但是JVM堆內(nèi)存和GC沒有明顯異常。CPU 空閑率基本都是0%，但是CPU使用率并不高，反而IO等待卻非常高。下面是執(zhí)行top命令查看CPU狀況的截圖：

從上圖，我們可以看到:

CPU空閑率是0%（上圖中紅框id）

CPU使用率是22%（上圖中紅框 us 13% 加上 sy 9%，us可以理解成用戶進(jìn)程占用的CPU，sy可以理解成系統(tǒng)進(jìn)程占用的CPU）

CPU 在等待磁盤IO操作上花費(fèi)的時(shí)間占比是76.6% （上圖中紅框 wa）

到現(xiàn)在可以確定，問題肯定發(fā)生在IO等待上。利用監(jiān)控系統(tǒng)和jstack命令，最終定位問題發(fā)生在文件寫入上。大量的磁盤讀寫導(dǎo)致了系統(tǒng)線程資源耗盡。最終導(dǎo)致訂單服務(wù)無法響應(yīng)上游服務(wù)的請(qǐng)求。

具體原因：當(dāng)時(shí)剛好趕上一次促銷活動(dòng)，我們當(dāng)時(shí)的日志框架采用的log4j，大家知道log4j有性能瓶頸，高并發(fā)時(shí)I/O等待很明顯，再加上當(dāng)時(shí)采用同步記錄日志的方式，這就導(dǎo)致了大量線程阻塞，最終導(dǎo)致線程池線程資源全部耗盡。當(dāng)時(shí)的解決辦法就是日志框架改成更高效的logback，再把記錄日志改成異步的方式，問題解決。

I/O，你不知道的那些事兒

既然I/O對(duì)系統(tǒng)性能和穩(wěn)定性影響這么大，我們就來深入探究一下。

所謂的I/O（Input/Output）操作實(shí)際上就是輸入輸出的數(shù)據(jù)傳輸行為。程序員最關(guān)注的主要是磁盤IO和網(wǎng)絡(luò)IO，因?yàn)檫@兩個(gè)IO操作和應(yīng)用程序的關(guān)系最直接最緊密。

磁盤IO：磁盤的輸入輸出，比如磁盤和內(nèi)存之間的數(shù)據(jù)傳輸。

網(wǎng)絡(luò)IO：不同系統(tǒng)間跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸，比如兩個(gè)系統(tǒng)間的遠(yuǎn)程接口調(diào)用。

下面這張圖展示了應(yīng)用程序中發(fā)生IO的具體場景：

通過上圖，我們可以了解到IO操作發(fā)生的具體場景。一個(gè)請(qǐng)求過程可能會(huì)發(fā)生很多次的IO操作：

1，頁面請(qǐng)求到服務(wù)器會(huì)發(fā)生網(wǎng)絡(luò)IO

2，服務(wù)之間遠(yuǎn)程調(diào)用會(huì)發(fā)生網(wǎng)絡(luò)IO

3，應(yīng)用程序訪問數(shù)據(jù)庫會(huì)發(fā)生網(wǎng)絡(luò)IO

4，數(shù)據(jù)庫查詢或者寫入數(shù)據(jù)會(huì)發(fā)生磁盤IO

IO和CPU的關(guān)系

不少攻城獅會(huì)這樣理解，如果CPU空閑率是0%，就代表CPU已經(jīng)在滿負(fù)荷工作，沒精力再處理其他任務(wù)了。真是這樣的嗎？

我們先看一下計(jì)算機(jī)是怎么管理磁盤IO操作的。計(jì)算機(jī)發(fā)展早期，磁盤和內(nèi)存的數(shù)據(jù)傳輸是由CPU控制的，也就是說從磁盤讀取數(shù)據(jù)到內(nèi)存中，是需要CPU存儲(chǔ)和轉(zhuǎn)發(fā)的，期間CPU一直會(huì)被占用。我們知道磁盤的讀寫速度遠(yuǎn)遠(yuǎn)比不上CPU的運(yùn)轉(zhuǎn)速度。這樣在傳輸數(shù)據(jù)時(shí)就會(huì)占用大量CPU資源，造成CPU資源嚴(yán)重浪費(fèi)。

后來有人設(shè)計(jì)了一個(gè)IO控制器，專門控制磁盤IO。當(dāng)發(fā)生磁盤和內(nèi)存間的數(shù)據(jù)傳輸前，CPU會(huì)給IO控制器發(fā)送指令，讓IO控制器負(fù)責(zé)數(shù)據(jù)傳輸操作，數(shù)據(jù)傳輸完IO控制器再通知CPU。因此，從磁盤讀取數(shù)據(jù)到內(nèi)存的過程就不再需要CPU參與了，CPU可以空出來處理其他事情，大大提高了CPU利用率。這個(gè)IO控制器就是“DMA”，即直接內(nèi)存訪問，Direct Memory Access。現(xiàn)在的計(jì)算機(jī)基本都采用這種DMA模式進(jìn)行數(shù)據(jù)傳輸。

通過上面內(nèi)容我們了解到，IO數(shù)據(jù)傳輸時(shí)，是不占用CPU的。當(dāng)應(yīng)用進(jìn)程或線程發(fā)生IO等待時(shí)，CPU會(huì)及時(shí)釋放相應(yīng)的時(shí)間片資源并把時(shí)間片分配給其他進(jìn)程或線程使用，從而使CPU資源得到充分利用。所以，假如CPU大部分消耗在IO等待（wa）上時(shí)，即便CPU空閑率（id）是0%，也并不意味著CPU資源完全耗盡了，如果有新的任務(wù)來了，CPU仍然有精力執(zhí)行任務(wù)。如下圖：

在DMA模式下執(zhí)行IO操作是不占用CPU的，所以CPU IO等待（上圖的wa）實(shí)際上屬于CPU空閑率的一部分。所以我們執(zhí)行top命令時(shí)，除了要關(guān)注CPU空閑率，CPU使用率（us，sy），還要關(guān)注IO Wait（wa）。注意，wa只代表磁盤IO Wait，不包括網(wǎng)絡(luò)IO Wait。

Java中線程狀態(tài)和IO的關(guān)系

當(dāng)我們用jstack查看Java線程狀態(tài)時(shí)，會(huì)看到各種線程狀態(tài)。當(dāng)發(fā)生IO等待時(shí)（比如遠(yuǎn)程調(diào)用時(shí)），線程是什么狀態(tài)呢，Blocked還是Waiting？

答案是Runnable狀態(tài)，是不是有些出乎意料！實(shí)際上，在操作系統(tǒng)層面Java的Runnable狀態(tài)除了包括Running狀態(tài)，還包括Ready（就緒狀態(tài)，等待CPU調(diào)度）和IO Wait等狀態(tài)。

如上圖，Runnable狀態(tài)的注解明確說明了，在JVM層面執(zhí)行的線程，在操作系統(tǒng)層面可能在等待其他資源。如果等待的資源是CPU，在操作系統(tǒng)層面線程就是等待被CPU調(diào)度的Ready狀態(tài)；如果等待的資源是磁盤網(wǎng)卡等IO資源，在操作系統(tǒng)層面線程就是等待IO操作完成的IO Wait狀態(tài)。

有人可能會(huì)問，為什么Java線程沒有專門的Running狀態(tài)呢？

目前絕大部分主流操作系統(tǒng)都是以時(shí)間分片的方式對(duì)任務(wù)進(jìn)行輪詢調(diào)度，時(shí)間片通常很短，大概幾十毫秒，也就是說一個(gè)線程每次在cpu上只能執(zhí)行幾十毫秒，然后就會(huì)被CPU調(diào)度出來變成Ready狀態(tài)，等待再一次被CPU執(zhí)行，線程在Ready和Running兩個(gè)狀態(tài)間快速切換。通常情況，JVM線程狀態(tài)主要為了監(jiān)控使用，是給人看的。當(dāng)你看到線程狀態(tài)是Running的一瞬間，線程狀態(tài)早已經(jīng)切換N次了。所以，再給線程專門加一個(gè)Running狀態(tài)也就沒什么意義了。

深入理解網(wǎng)絡(luò)IO模型

5種Linux網(wǎng)絡(luò)IO模型包括：同步阻塞IO、同步非阻塞IO、多路復(fù)用IO、信號(hào)驅(qū)動(dòng)IO和異步IO。

寫在前面

為了更好地理解網(wǎng)絡(luò)IO模型，我們先了解幾個(gè)基本概念。

Socket（套接字）：Socket可以理解成，在兩個(gè)應(yīng)用程序進(jìn)行網(wǎng)絡(luò)通信時(shí)，分別在兩個(gè)應(yīng)用程序中的通信端點(diǎn)。通信時(shí)，一個(gè)應(yīng)用程序?qū)?shù)據(jù)寫入Socket，然后通過網(wǎng)卡把數(shù)據(jù)發(fā)送到另外一個(gè)應(yīng)用程序的Socket中。我們平常所說的HTTP和TCP協(xié)議的遠(yuǎn)程通信，底層都是基于Socket實(shí)現(xiàn)的。5種網(wǎng)絡(luò)IO模型也都要基于Socket實(shí)現(xiàn)網(wǎng)絡(luò)通信。

阻塞與非阻塞：所謂阻塞，就是發(fā)出一個(gè)請(qǐng)求不能立刻返回響應(yīng)，要等所有的邏輯全處理完才能返回響應(yīng)。非阻塞反之，發(fā)出一個(gè)請(qǐng)求立刻返回應(yīng)答，不用等處理完所有邏輯。

內(nèi)核空間與用戶空間：在Linux中，應(yīng)用程序穩(wěn)定性遠(yuǎn)遠(yuǎn)比不上操作系統(tǒng)程序，為了保證操作系統(tǒng)的穩(wěn)定性，Linux區(qū)分了內(nèi)核空間和用戶空間?？梢赃@樣理解，內(nèi)核空間運(yùn)行操作系統(tǒng)程序和驅(qū)動(dòng)程序，用戶空間運(yùn)行應(yīng)用程序。Linux以這種方式隔離了操作系統(tǒng)程序和應(yīng)用程序，避免了應(yīng)用程序影響到操作系統(tǒng)自身的穩(wěn)定性。這也是Linux系統(tǒng)超級(jí)穩(wěn)定的主要原因。所有的系統(tǒng)資源操作都在內(nèi)核空間進(jìn)行，比如讀寫磁盤文件，內(nèi)存分配和回收，網(wǎng)絡(luò)接口調(diào)用等。所以在一次網(wǎng)絡(luò)IO讀取過程中，數(shù)據(jù)并不是直接從網(wǎng)卡讀取到用戶空間中的應(yīng)用程序緩沖區(qū)，而是先從網(wǎng)卡拷貝到內(nèi)核空間緩沖區(qū)，然后再從內(nèi)核拷貝到用戶空間中的應(yīng)用程序緩沖區(qū)。對(duì)于網(wǎng)絡(luò)IO寫入過程，過程則相反，先將數(shù)據(jù)從用戶空間中的應(yīng)用程序緩沖區(qū)拷貝到內(nèi)核緩沖區(qū)，再從內(nèi)核緩沖區(qū)把數(shù)據(jù)通過網(wǎng)卡發(fā)送出去。

同步阻塞IO

我們先看一下傳統(tǒng)阻塞IO。在Linux中，默認(rèn)情況下所有socket都是阻塞模式的。當(dāng)用戶線程調(diào)用系統(tǒng)函數(shù)read()，內(nèi)核開始準(zhǔn)備數(shù)據(jù)（從網(wǎng)絡(luò)接收數(shù)據(jù)），內(nèi)核準(zhǔn)備數(shù)據(jù)完成后，數(shù)據(jù)從內(nèi)核拷貝到用戶空間的應(yīng)用程序緩沖區(qū)，數(shù)據(jù)拷貝完成后，請(qǐng)求才返回。從發(fā)起read請(qǐng)求到最終完成內(nèi)核到應(yīng)用程序的拷貝，整個(gè)過程都是阻塞的。為了提高性能，可以為每個(gè)連接都分配一個(gè)線程。因此，在大量連接的場景下就需要大量的線程，會(huì)造成巨大的性能損耗，這也是傳統(tǒng)阻塞IO的最大缺陷。

同步非阻塞IO

用戶線程在發(fā)起Read請(qǐng)求后立即返回，不用等待內(nèi)核準(zhǔn)備數(shù)據(jù)的過程。如果Read請(qǐng)求沒讀取到數(shù)據(jù)，用戶線程會(huì)不斷輪詢發(fā)起Read請(qǐng)求，直到數(shù)據(jù)到達(dá)（內(nèi)核準(zhǔn)備好數(shù)據(jù)）后才停止輪詢。非阻塞IO模型雖然避免了由于線程阻塞問題帶來的大量線程消耗，但是頻繁的重復(fù)輪詢大大增加了請(qǐng)求次數(shù)，對(duì)CPU消耗也比較明顯。這種模型在實(shí)際應(yīng)用中很少使用。

多路復(fù)用IO模型

多路復(fù)用IO模型，建立在多路事件分離函數(shù)select，poll，epoll之上。在發(fā)起read請(qǐng)求前，先更新select的socket監(jiān)控列表，然后等待select函數(shù)返回（此過程是阻塞的，所以說多路復(fù)用IO也是阻塞IO模型）。當(dāng)某個(gè)socket有數(shù)據(jù)到達(dá)時(shí)，select函數(shù)返回。此時(shí)用戶線程才正式發(fā)起read請(qǐng)求，讀取并處理數(shù)據(jù)。這種模式用一個(gè)專門的監(jiān)視線程去檢查多個(gè)socket，如果某個(gè)socket有數(shù)據(jù)到達(dá)就交給工作線程處理。由于等待Socket數(shù)據(jù)到達(dá)過程非常耗時(shí)，所以這種方式解決了阻塞IO模型一個(gè)Socket連接就需要一個(gè)線程的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU性能損耗的問題。多路復(fù)用IO模型的實(shí)際應(yīng)用場景很多，比如大家耳熟能詳?shù)腏ava NIO，Redis以及Dubbo采用的通信框架Netty都采用了這種模型。

下圖是基于select函數(shù)Socket編程的詳細(xì)流程。

信號(hào)驅(qū)動(dòng)IO模型

信號(hào)驅(qū)動(dòng)IO模型，應(yīng)用進(jìn)程使用sigaction函數(shù)，內(nèi)核會(huì)立即返回，也就是說內(nèi)核準(zhǔn)備數(shù)據(jù)的階段應(yīng)用進(jìn)程是非阻塞的。內(nèi)核準(zhǔn)備好數(shù)據(jù)后向應(yīng)用進(jìn)程發(fā)送SIGIO信號(hào)，接到信號(hào)后數(shù)據(jù)被復(fù)制到應(yīng)用程序進(jìn)程。

采用這種方式，CPU的利用率很高。不過這種模式下，在大量IO操作的情況下可能造成信號(hào)隊(duì)列溢出導(dǎo)致信號(hào)丟失，造成災(zāi)難性后果。

異步IO模型

異步IO模型的基本機(jī)制是，應(yīng)用進(jìn)程告訴內(nèi)核啟動(dòng)某個(gè)操作，內(nèi)核操作完成后再通知應(yīng)用進(jìn)程。在多路復(fù)用IO模型中，socket狀態(tài)事件到達(dá)，得到通知后，應(yīng)用進(jìn)程才開始自行讀取并處理數(shù)據(jù)。在異步IO模型中，應(yīng)用進(jìn)程得到通知時(shí)，內(nèi)核已經(jīng)讀取完數(shù)據(jù)并把數(shù)據(jù)放到了應(yīng)用進(jìn)程的緩沖區(qū)中，此時(shí)應(yīng)用進(jìn)程

直接使用數(shù)據(jù)即可。

很明顯，異步IO模型性能很高。不過到目前為止，異步IO和信號(hào)驅(qū)動(dòng)IO模型應(yīng)用并不多見，傳統(tǒng)阻塞IO和多路復(fù)用IO模型還是目前應(yīng)用的主流。Linux2.6版本后才引入異步IO模型，目前很多系統(tǒng)對(duì)異步IO模型支持尚不成熟。很多應(yīng)用場景采用多路復(fù)用IO替代異步IO模型。

如何避免IO問題帶來的系統(tǒng)故障

對(duì)于磁盤文件訪問的操作，可以采用線程池方式，并設(shè)置線程上線，從而避免整個(gè)JVM線程池污染，進(jìn)而導(dǎo)致線程和CPU資源耗盡。

對(duì)于網(wǎng)絡(luò)間遠(yuǎn)程調(diào)用。為了避免服務(wù)間調(diào)用的全鏈路故障，要設(shè)置合理的TImeout值，高并發(fā)場景下可以采用熔斷機(jī)制。在同一JVM內(nèi)部采用線程隔離機(jī)制，把線程分為若干組，不同的線程組分別服務(wù)于不同的類和方法，避免因?yàn)橐粋€(gè)小功能點(diǎn)的故障，導(dǎo)致JVM內(nèi)部所有線程受到影響。

此外，完善的運(yùn)維監(jiān)控（磁盤IO，網(wǎng)絡(luò)IO）和APM（全鏈路性能監(jiān)控）也非常重要，能及時(shí)預(yù)警，防患于未然，在故障發(fā)生時(shí)也能幫助我們快速定位問題。

就分享到這。原創(chuàng)不易，如果感覺本文對(duì)您有幫助，有勞點(diǎn)一下“在看”！

作者簡介：曾任職于阿里巴巴，每日優(yōu)鮮等互聯(lián)網(wǎng)公司，任技術(shù)總監(jiān)，15年電商互聯(lián)網(wǎng)經(jīng)歷。