一、先知概念
參考：https://www.jianshu.com/p/486b0965c296
但是我想說一下，鏈接中的這篇文章，有個概念是錯的，它裏面貼了一張圖，把I/O多路複用歸類到異步阻塞中。我認爲不存在異步阻塞這種概念。
1.1 用戶空間與內核空間
現在操作系統都是採用虛擬存儲器，那麼對32位操作系統而言，它的尋址空間（虛擬存儲空間）爲4G（2的32次方）。操作系統的核心是內核，獨立於普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。爲了保證用戶進程不能直接操作內核（kernel），保證內核的安全，操作系統將虛擬空間劃分爲兩部分，一部分爲內核空間，一部分爲用戶空間。針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱爲內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱爲用戶空間。
1.2 進程切換
爲了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，並恢復以前掛起的某個進程的執行。這種行爲被稱爲進程切換。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。
從一個進程的運行轉到另一個進程上運行，這個過程中經過下面這些變化：
保存處理機上下文，包括程序計數器和其他寄存器。
更新PCB信息。
把進程的PCB移入相應的隊列，如就緒、在某事件阻塞等隊列。
選擇另一個進程執行，並更新其PCB。
更新內存管理的數據結構。
恢復處理機上下文。
注：總而言之就是很耗資源，具體的可以參考這篇文章：進程切換。
1.3 進程的阻塞
正在執行的進程，由於期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變爲阻塞狀態。可見，進程的阻塞是進程自身的一種主動行爲，也因此只有處於運行態的進程（獲得CPU），纔可能將其轉爲阻塞狀態。當進程進入阻塞狀態，是不佔用CPU資源的。
1.4 文件描述符fd
文件描述符（File descriptor）是計算機科學中的一個術語，是一個用於表述指向文件的引用的抽象化概念。
文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核爲每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞着文件描述符展開。但是文件描述符這一概念往往只適用於UNIX、Linux這樣的操作系統。
1.5 緩存 IO##
緩存 IO 又被稱作標準 IO，大多數文件系統的默認 IO 操作都是緩存 IO。在 Linux 的緩存 IO 機制中，操作系統會將 IO 的數據緩存在文件系統的頁緩存（ page cache ）中，也就是說，數據會先被拷貝到操作系統內核的緩衝區中，然後纔會從操作系統內核的緩衝區拷貝到應用程序的地址空間。
緩存 IO 的缺點：
數據在傳輸過程中需要在應用程序地址空間和內核進行多次數據拷貝操作，這些數據拷貝操作所帶來的 CPU 以及內存開銷是非常大的。
二、同步、異步、阻塞、非阻塞
參考：
https://blog.csdn.net/lengxiao1993/article/details/78154467，該文介紹了同步、異步、阻塞、非阻塞、用戶空間、內核空間
我自己的理解就是
阻塞、非阻塞的區別在於：等待結果的過程中，線程/進程是否被掛起、讓出了CPU。
同步、異步的區別在於：本次調用的返回是否爲一個確切的結果。
而關於同步、異步的理解，鑫大爺的跟我的完全不一樣，他的理解是：
同步是由用戶空間線程發起調用並等待操作完成。
異步是由用戶空間線程發起調用且不等待操作完成，之後由內核空間完成操作並通知用戶空間線程。
同步異步區別：同步是由用戶空間發起調用並完成操作，異步是由用戶空間發起調用內核空間完成操作
三、IO的5中模型
參考：https://blog.csdn.net/historyasamirror/article/details/5778378
對於一個network IO (這裏我們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)及用戶空間，另一個就是系統內核(kernel)。
當一個read操作發生時，它會經歷兩個階段：
1 等待數據準備 (Waiting for the data to be ready)
2 將數據從內核拷貝到進程（用戶空間）中 (Copying the data from the kernel to the process)
IO Model的區別就是在兩個階段上各有不同的情況。
1.blocking IO 同步阻塞
在linux中，默認情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：
在等待數據和拷貝數據這兩個階段用戶進程/線程都被阻塞了。
當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。
而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
2.nonblocking IO 同步非阻塞
linux下，可以通過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：
第一階段等待數據時：用戶進程/線程沒有被阻塞，沒有釋放CPU，它在不停的詢問內核數據來了沒
當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個error。
從用戶進程角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。
用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。
第二階段拷貝數據時：
一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶內存，然後返回。
3.IO multiplexing 多路複用
select/epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖
當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並沒有太大的不同，事實上，還更差一些。因爲這裏需要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。（多說一句。所以，如果處理的連接數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連接能處理得更快，而是在於能處理更多的連接。）
在IO multiplexing Model中，實際中，對於每一個socket，一般都設置成爲non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。
netty就是這種模型，Java的NIO就是這種模型
4.signal driven IO 信號驅動
5.asynchronous IO 異步非阻塞
第一階段等待數據和第二階段拷貝數據，用戶進程/線程都不會被阻塞
用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
6.各個IO Model的比較如圖所示：
