你真的了解多線程嗎?

如果問你“為什么多線程可以提高程序運行效率?”，想必你會說“計算機并行執行任務啊，當然效率高!” 這顯然不是一個內行該給出的答案。要知道，一個 CPU 在任何時間點上只能干一件事情啊，如果執行了指令 A，就不能執行指令 B 了，何來并行呢?想要真正理解多線程，必須得先弄清 Linux 中的 I/O 機制。

什么是 Linux I/O ?

一般指文件讀取/寫入、網卡讀取/寫入。不管是文件 I/O，還是網卡 I/O，其準備數據速度都遠遠低于 CPU 處理數據的速度 。磁盤讀數據，毫秒級別，最慢。其次是網卡，微秒。再就是內存，納秒，最快的是緩存。

下圖顯示了一個 Linux 進程(只有一個主線程)的執行過程：

用戶進程向 CPU 發起 read 請求，CPU 向 DMA 發起 I/O 請求，DMA 再向磁盤發起 I/O 請求。這里的 DMA 全稱為 Direct Memory Access，你可以簡單理解為 CPU 內存和磁盤之間的代理。

磁盤向 CPU 發起 I/O 中斷，CPU 拷貝數據，先是內核態 buffer，再到用戶態 buffer。

用戶進程從內核態切回用戶態，阻塞狀態結束，程序繼續執行，直到結束。

上述流程中，用戶進程在拿到磁盤數據之前，只能原地等待，也就是處于阻塞狀態，這個時候 CPU 就空閑了，顯然造成了 CPU 資源的浪費。這個時候如果在該進程內拉起另一個線程 T，那么 T 就可以見縫插針，在主線程等待數據的過程中， 把 CPU 的閑置資源利用起來，豈不美哉!這就是多線程技術的由來。

總有一些概念把人繞暈 -- 同步/異步、阻塞/非阻塞

在學習多線程技術的過程中，總有一些概念時不時蹦出來，比如同步/異步、阻塞/非阻塞，如果你是一位并發領域的高手，那么這些都是小兒科。如果你是一位初學者，那么你很可能陷入其中，不能自拔，從而最終放棄。接下來，我們嘗試終結這個問題，帶你爬出這個坑。

舉個例子：

假如某一天你要去銀行辦理某項業務，到了銀行，首先要憑身份證取個號。取完號之后，你發現這天人特別多，于是你就要等，等著被叫號。在等待的過程中，你可以有以下幾個選擇：

選擇 1： 啥也不干，死盯著銀行的液晶顯示屏，等到出現你的號碼時，你趕緊起身直奔柜臺，銀行叫號系統甚至還沒來得及叫你的號。那么，在這段時間內，你就處于阻塞狀態，而且你和銀行叫號系統之間的關系是同步的。“阻塞”好理解，因為你啥也沒干嘛!“同步”怎么理解呢?因為你和銀行叫號系統的步調要保持一致，當顯示屏上出現你的號時，你就得立馬去柜臺辦業務，而銀行自動廣播喊你的功能對你來說，是沒必要的。

選擇 2：你還是啥也不干，但是你坐在座位上開始冥想，做著白日夢。因為你知道，輪到你的時候，銀行叫號系統會廣播叫你的。聽到廣播后，你再起身去柜臺也不遲。那么在這段時間內，你還是處于阻塞狀態。而你和銀行叫號系統之間的關系是異步的，因為你不用再關注屏幕上滾動的號碼，輪到你的時候，自然它會廣播告訴你。

選擇 3：對于一個聰明的人，顯然不會坐在那傻等或者胡思亂想了。這時候，你拿起手機，決定打一把王者榮耀，打游戲的過程中，你還是時不時瞄一眼顯示屏，等看到你的號碼時，立馬起身去柜臺。那么這段時間內，你就處于非阻塞狀態，因為你還干其他事了呀。但你和銀行叫號系統間的關系還是同步的。

選擇 4：如果你打算專心致志地玩一把王者榮耀，不想坑隊友。那么你就等著廣播叫你就可以了。那么這段時間內，你就處于非阻塞的狀態，而且和銀行叫號系統之間的關系還是異步的。

好了，總結一下：

所謂阻塞就是請求者發起讀取數據的函數調用時，當數據還沒準備好，這時如果函數一直在等待返回結果，就是阻塞;反之如果函數即刻返回，繼續執行后面的動作就是非阻塞。

在 I/O 模型里，如果請求方從發起請求到數據最后準備好的這一段過程中都需要自己參與，那么這種我們稱為同步請求;反之，如果應用發送完指令后就不再參與過程了，只需要等待最終完成結果的通知，那么這就屬于異步。

哦，對了。上述選擇 2 你也可以認為是 選擇 4，因為你只要等待銀行廣播叫你就可以呀，做白日夢也可以認為是在干自己的事嘛!

再談多線程

所謂多線程，就是多個線程在一個進程里同時運行，它們之間可以是協作的關系，一起完成某個共同的任務，也可以各干各的事。不管協作，還是單干，總有一個問題繞不開：“CPU 的資源怎么分配?”多線程之間爭奪資源的過程可以認為是一種“零和博弈”，線程 A 搶奪的資源多，那么線程 B 得到的資源必然就少了嘛!一般來說，用戶只會關心 CPU 總的利用率，這個值越大越好，而不用關注具體每個線程得到的計算資源是多是少。