幾年前的一個下午，公司里碼農們正在安靜地敲著代碼，突然很多人的手機同時“嗶嗶”地響了起來，本來以為發工資了，都挺高興！打開一看，原來是告警短信
故障回顧
告警提示“執行緒數過多，超出閾值”，“CPU空閑率太低”，打開監控系統一看，訂單服務所有20個服務節點都不行了，服務沒回應，
每個springboot節點執行緒數全都達到了最大值，但是JVM堆記憶體和GC沒有明顯例外，CPU 空閑率基本都是0%，但是CPU使用率并不高，反而IO等待卻非常高，下面是執行top命令查看CPU狀況的截圖：
從上圖，我們可以看到:
CPU空閑率是0%（上圖中紅框id）
CPU使用率是22%（上圖中紅框 us 13% 加上 sy 9%，us可以理解成用戶行程占用的CPU，sy可以理解成系統行程占用的CPU）
CPU 在等待磁盤IO操作上花費的時間占比是76.6% （上圖中紅框 wa）
到現在可以確定，問題肯定發生在IO等待上，利用監控系統和jstack命令，最終定位問題發生在檔案寫入上，大量的磁盤讀寫導致了JVM執行緒資源耗盡（注意，不代表系統CPU耗盡），最終導致訂單服務無法回應上游服務的請求，
IO，你不知道的那些事兒
既然IO對系統性能和穩定性影響這么大，我們就來深入探究一下，
所謂的I/O（Input/Output）操作實際上就是輸入輸出的資料傳輸行為，程式員最關注的主要是磁盤IO和網路IO，因為這兩個IO操作和應用程式的關系最直接最緊密，
磁盤IO：磁盤的輸入輸出，比如磁盤和記憶體之間的資料傳輸，
網路IO：不同系統間跨網路的資料傳輸，比如兩個系統間的遠程介面呼叫，
下面這張圖展示了應用程式中發生IO的具體場景：
通過上圖，我們可以了解到IO操作發生的具體場景，一個請求程序可能會發生很多次的IO操作：
-
頁面請求到服務器會發生網路IO
-
服務之間遠程呼叫會發生網路IO
-
應用程式訪問資料庫會發生網路IO
-
資料庫查詢或者寫入資料會發生磁盤IO
IO和CPU的關系
不少攻城獅會這樣理解，如果CPU空閑率是0%，就代表CPU已經在滿負荷作業，沒精力再處理其他任務了，真是這樣的嗎？
我們先看一下計算機是怎么管理磁盤IO操作的，計算機發展早期，磁盤和記憶體的資料傳輸是由CPU控制的，也就是說從磁盤讀取資料到記憶體中，是需要CPU存盤和轉發的，期間CPU一直會被占用，我們知道磁盤的讀寫速度遠遠比不上CPU的運轉速度，這樣在傳輸資料時就會占用大量CPU資源，造成CPU資源嚴重浪費，
后來有人設計了一個IO控制器，專門控制磁盤IO，當發生磁盤和記憶體間的資料傳輸前，CPU會給IO控制器發送指令，讓IO控制器負責資料傳輸操作，資料傳輸完IO控制器再通知CPU，因此，從磁盤讀取資料到記憶體的程序就不再需要CPU參與了，CPU可以空出來處理其他事情，大大提高了CPU利用率，這個IO控制器就是“DMA”，即直接記憶體訪問，Direct Memory Access，現在的計算機基本都采用這種DMA模式進行資料傳輸，
通過上面內容我們了解到，IO資料傳輸時，是不占用CPU的，當應用行程或執行緒發生IO等待時，CPU會及時釋放相應的時間片資源并把時間片分配給其他行程或執行緒使用，從而使CPU資源得到充分利用，所以，假如CPU大部分消耗在IO等待（wa）上時，即便CPU空閑率（id）是0%，也并不意味著CPU資源完全耗盡了，如果有新的任務來了，CPU仍然有精力執行任務，如下圖：
在DMA模式下執行IO操作是不占用CPU的，所以CPU IO等待（上圖的wa）實際上屬于CPU空閑率的一部分，所以我們執行top命令時，除了要關注CPU空閑率，CPU使用率（us，sy），還要關注IO Wait（wa），注意，wa只代表磁盤IO Wait，不包括網路IO Wait，
Java中執行緒狀態和IO的關系
當我們用jstack查看Java執行緒狀態時，會看到各種執行緒狀態，當發生IO等待時（比如遠程呼叫時），執行緒是什么狀態呢，Blocked還是Waiting？
答案是Runnable狀態，是不是有些出乎意料！實際上，在作業系統層面Java的Runnable狀態除了包括Running狀態，還包括Ready（就緒狀態，等待CPU調度）和IO Wait等狀態，
如上圖，Runnable狀態的注解明確說明了，在JVM層面執行的執行緒，在作業系統層面可能在等待其他資源，如果等待的資源是CPU，在作業系統層面執行緒就是等待被CPU調度的Ready狀態；如果等待的資源是磁盤網卡等IO資源，在作業系統層面執行緒就是等待IO操作完成的IO Wait狀態，
有人可能會問，為什么Java執行緒沒有專門的Running狀態呢？
目前絕大部分主流作業系統都是以時間分片的方式對任務進行輪詢調度，時間片通常很短，大概幾十毫秒，也就是說一個執行緒每次在cpu上只能執行幾十毫秒，然后就會被CPU調度出來變成Ready狀態，等待再一次被CPU執行，執行緒在Ready和Running兩個狀態間快速切換，通常情況，JVM執行緒狀態主要為了監控使用，是給人看的，當你看到執行緒狀態是Running的一瞬間，執行緒狀態早已經切換N次了，所以，再給執行緒專門加一個Running狀態也就沒什么意義了，
深入理解網路IO模型
5種Linux網路IO模型包括：同步阻塞IO、同步非阻塞IO、多路復用IO、信號驅動IO和異步IO，
寫在前面
為了更好地理解網路IO模型，我們先了解幾個基本概念，
Socket（套接字）：Socket可以理解成，在兩個應用程式進行網路通信時，分別在兩個應用程式中的通信端點，通信時，一個應用程式將資料寫入Socket，然后通過網卡把資料發送到另外一個應用程式的Socket中，我們平常所說的HTTP和TCP協議的遠程通信，底層都是基于Socket實作的，5種網路IO模型也都要基于Socket實作網路通信，
阻塞與非阻塞：所謂阻塞，就是發出一個請求不能立刻回傳回應，要等所有的邏輯全處理完才能回傳回應，非阻塞反之，發出一個請求立刻回傳應答，不用等處理完所有邏輯，
內核空間與用戶空間：在Linux中，應用程式穩定性遠遠比不上作業系統程式，為了保證作業系統的穩定性，Linux區分了內核空間和用戶空間，可以這樣理解，內核空間運行作業系統程式和驅動程式，用戶空間運行應用程式，Linux以這種方式隔離了作業系統程式和應用程式，避免了應用程式影響到作業系統自身的穩定性，這也是Linux系統超級穩定的主要原因，所有的系統資源操作都在內核空間進行，比如讀寫磁盤檔案，記憶體分配和回收，網路介面呼叫等，所以在一次網路IO讀取程序中，資料并不是直接從網卡讀取到用戶空間中的應用程式緩沖區，而是先從網卡拷貝到內核空間緩沖區，然后再從內核拷貝到用戶空間中的應用程式緩沖區，對于網路IO寫入程序，程序則相反，先將資料從用戶空間中的應用程式緩沖區拷貝到內核緩沖區，再從內核緩沖區把資料通過網卡發送出去，
同步阻塞IO
我們先看一下傳統阻塞IO，在Linux中，默認情況下所有socket都是阻塞模式的，當用戶執行緒呼叫系統函式read()，內核開始準備資料（從網路接收資料），內核準備資料完成后，資料從內核拷貝到用戶空間的應用程式緩沖區，資料拷貝完成后，請求才回傳，從發起read請求到最終完成內核到應用程式的拷貝，整個程序都是阻塞的，為了提高性能，可以為每個連接都分配一個執行緒，因此，在大量連接的場景下就需要大量的執行緒，會造成巨大的性能損耗，這也是傳統阻塞IO的最大缺陷，
同步非阻塞IO
用戶執行緒在發起Read請求后立即回傳，不用等待內核準備資料的程序，如果Read請求沒讀取到資料，用戶執行緒會不斷輪詢發起Read請求，直到資料到達（內核準備好資料）后才停止輪詢，非阻塞IO模型雖然避免了由于執行緒阻塞問題帶來的大量執行緒消耗，但是頻繁的重復輪詢大大增加了請求次數，對CPU消耗也比較明顯，這種模型在實際應用中很少使用，
多路復用IO模型
多路復用IO模型，建立在多路事件分離函式select，poll，epoll之上，在發起read請求前，先更新select的socket監控串列，然后等待select函式回傳（此程序是阻塞的，所以說多路復用IO也是阻塞IO模型），當某個socket有資料到達時，select函式回傳，此時用戶執行緒才正式發起read請求，讀取并處理資料，這種模式用一個專門的監視執行緒去檢查多個socket，如果某個socket有資料到達就交給作業執行緒處理，由于等待Socket資料到達程序非常耗時，所以這種方式解決了阻塞IO模型一個Socket連接就需要一個執行緒的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU性能損耗的問題，多路復用IO模型的實際應用場景很多，比如大家耳熟能詳的Java NIO，Redis以及Dubbo采用的通信框架Netty都采用了這種模型，
下圖是基于select函式Socket編程的詳細流程，
信號驅動IO模型
信號驅動IO模型，應用行程使用sigaction函式，內核會立即回傳，也就是說內核準備資料的階段應用行程是非阻塞的，內核準備好資料后向應用行程發送SIGIO信號，接到信號后資料被復制到應用程式行程，
采用這種方式，CPU的利用率很高，不過這種模式下，在大量IO操作的情況下可能造成信號佇列溢位導致信號丟失，造成災難性后果，
異步IO模型
異步IO模型的基本機制是，應用行程告訴內核啟動某個操作，內核操作完成后再通知應用行程，在多路復用IO模型中，socket狀態事件到達，得到通知后，應用行程才開始自行讀取并處理資料，在異步IO模型中，應用行程得到通知時，內核已經讀取完資料并把資料放到了應用行程的緩沖區中，此時應用行程直接使用資料即可，
很明顯，異步IO模型性能很高，不過到目前為止，異步IO和信號驅動IO模型應用并不多見，傳統阻塞IO和多路復用IO模型還是目前應用的主流，Linux2.6版本后才引入異步IO模型，目前很多系統對異步IO模型支持尚不成熟，很多應用場景采用多路復用IO替代異步IO模型，
如何避免IO問題帶來的系統故障
對于磁盤檔案訪問的操作，可以采用執行緒池方式，并設定執行緒上線，從而避免整個JVM執行緒池污染，進而導致執行緒和CPU資源耗盡，
對于網路間遠程呼叫，為了避免服務間呼叫的全鏈路故障，要設定合理的TImeout值，高并發場景下可以采用熔斷機制，在同一JVM內部采用執行緒隔離機制，把執行緒分為若干組，不同的執行緒組分別服務于不同的類和方法，避免因為一個小功能點的故障，導致JVM內部所有執行緒受到影響，
此外，完善的運維監控（磁盤IO，網路IO）和APM（全鏈路性能監控）也非常重要，能及時預警，防患于未然，在故障發生時也能幫助我們快速定位問題，
看完三件事??
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力，
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識，
-
同時可以期待后續文章ing??
本文作者：馮濤 來自公眾號：架構師進階之路
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/136232.html
標籤：Java