本文轉載自微信公眾號「日常加油站」，作者月伴飛魚。轉載本文請聯系日常加油站公眾號。

背景介紹

• 在互聯網的時代下，絕大部分數據都是通過網絡來進行獲取的。
• 在服務端的架構中，絕大部分數據也是通過網絡來進行交互的。

而且作為服務端的開發工程師來說，都會進行一系列服務設計、開發以及能力開放，而服務能力開放也是需要通過網絡來完成的，因此對網絡編程以及網絡IO模型都不會太陌生。

由于有很多優秀的框架(比如Netty、HSF、Dubbo、Thrift等)已經把底層網絡IO給封裝了，通過提供的API能力或者配置就能完成想要的服務能力開發，因此大部分工程師對網絡IO模型的底層不夠了解。

本文系統的講解了Linux內核的IO模型、Java網絡IO模型以及兩者之間的關系!

什么是IO

我們都知道在Linux的世界，一切皆文件。

而文件就是一串二進制流，不管Socket、FIFO、管道還是終端，對我們來說，一切都是流。

• 在信息的交換過程中，我們都是對這些流進行數據收發操作，簡稱為I/O操作。
• 往流中讀取數據，系統調用Read，寫入數據，系統調用Write。

通常用戶進程的一個完整的IO分為兩個階段：

磁盤IO：

網絡IO：

操作系統和驅動程序運行在內核空間，應用程序運行在用戶空間，兩者不能使用指針傳遞數據，因為Linux使用的虛擬內存機制，必須通過系統調用請求內核來完成IO動作。

IO有內存IO、網絡IO和磁盤IO三種，通常我們說的IO指的是后兩者!

為什么需要IO模型

如果使用同步的方式來通信的話，所有的操作都在一個線程內順序執行完成，這么做缺點是很明顯的：

• 因為同步的通信操作會阻塞同一個線程的其他任何操作，只有這個操作完成了之后，后續的操作才可以完成，所以出現了同步阻塞+多線程(每個Socket都創建一個線程對應)，但是系統內線程數量是有限制的，同時線程切換很浪費時間，適合Socket少的情況。

因該需要出現IO模型。

Linux的IO模型

在描述Linux IO模型之前，我們先來了解一下Linux系統數據讀取的過程：

以用戶請求index.html文件為例子說明

基本概念

用戶空間和內核空間

操作系統的核心是內核，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。

• 為了保證內核的安全，用戶進程不能直接操作內核，操作系統將虛擬空間劃分為兩部分，一部分為內核空間，一部分為用戶空間。

進程切換

為了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，并恢復以前掛起的某個進程的執行。

這種行為被稱為進程切換。

因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。

進程的阻塞

正在執行的進程，由于期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變為阻塞狀態。

可見，進程的阻塞是進程自身的一種主動行為，也因此只有處于運行態的進程(獲得CPU)，才可能將其轉為阻塞狀態。

當進程進入阻塞狀態，是不占用CPU資源的。

文件描述符

文件描述符(File Descriptor)是計算機科學中的一個術語，是一個用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一個非負整數，實際上，它是一個索引值，指向內核為每一個進程所維護的該進程打開文件的記錄表。

當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。

緩存IO

大多數文件系統的默認 IO 操作都是緩存 IO。

其讀寫過程如下：

• 讀操作：操作系統檢查內核的緩沖區有沒有需要的數據，如果已經緩存了，那么就直接從緩存中返回;否則從磁盤、網卡等中讀取，然后緩存在操作系統的緩存中;
• 寫操作：將數據從用戶空間復制到內核空間的緩存中。這時對用戶程序來說寫操作就已經完成，至于什么時候再寫到磁盤、網卡等中由操作系統決定，除非顯示地調用了 sync 同步命令。

假設內核空間緩存無需要的數據，用戶進程從磁盤或網絡讀數據分兩個階段：

• 階段一： 內核程序從磁盤、網卡等讀取數據到內核空間緩存區;
• 階段二： 用戶程序從內核空間緩存拷貝數據到用戶空間。

緩存 IO 的缺點：

數據在傳輸過程中需要在應用程序地址空間和內核空間進行多次數據拷貝操作，這些數據拷貝操作所帶來的CPU以及內存開銷非常大。

同步阻塞

用戶空間的應用程序執行一個系統調用，這會導致應用程序阻塞，什么也不干，直到數據準備好，并且將數據從內核復制到用戶進程，最后進程再處理數據，在等待數據到處理數據的兩個階段，整個進程都被阻塞，不能處理別的網絡IO。

• 調用應用程序處于一種不再消費 CPU 而只是簡單等待響應的狀態，因此從處理的角度來看，這是非常有效的。

這也是最簡單的IO模型，在通常FD較少、就緒很快的情況下使用是沒有問題的。

同步非阻塞

非阻塞的系統調用調用之后，進程并沒有被阻塞，內核馬上返回給進程，如果數據還沒準備好，此時會返回一個error。

• 進程在返回之后，可以干點別的事情，然后再發起系統調用。
• 重復上面的過程，循環往復的進行系統調用。這個過程通常被稱之為輪詢。
• 輪詢檢查內核數據，直到數據準備好，再拷貝數據到進程，進行數據處理。
• 需要注意，拷貝數據整個過程，進程仍然是屬于阻塞的狀態。
• 這種方式在編程中對Socket設置O_NONBLOCK即可。

IO多路復用

IO多路復用，這是一種進程預先告知內核的能力，讓內核發現進程指定的一個或多個IO條件就緒了，就通知進程。

使得一個進程能在一連串的事件上等待。

IO復用的實現方式目前主要有Select、Poll和Epoll。

偽代碼描述IO多路復用：

while(status == OK) { // 不斷輪詢
 ready_fd_list = io_wait(fd_list); //內核緩沖區是否有準備好的數據
 for(fd in ready_fd_list) {
  data = read(fd) // 有準備好的數據讀取到用戶緩沖區
  process(data)
 }
}

信號驅動

首先我們允許Socket進行信號驅動IO，并安裝一個信號處理函數，進程繼續運行并不阻塞。

當數據準備好時，進程會收到一個SIGIO信號，可以在信號處理函數中調用I/O操作函數處理數據。

流程如下：

• 開啟套接字信號驅動IO功能
• 系統調用Sigaction執行信號處理函數(非阻塞，立刻返回)
• 數據就緒，生成Sigio信號，通過信號回調通知應用來讀取數據

此種IO方式存在的一個很大的問題：Linux中信號隊列是有限制的，如果超過這個數字問題就無法讀取數據

異步非阻塞

異步IO流程如下所示：

• 當用戶線程調用了aio_read系統調用，立刻就可以開始去做其它的事，用戶線程不阻塞
• 內核就開始了IO的第一個階段：準備數據。當內核一直等到數據準備好了，它就會將數據從內核內核緩沖區，拷貝到用戶緩沖區
• 內核會給用戶線程發送一個信號，或者回調用戶線程注冊的回調接口，告訴用戶線程Read操作完成了
• 用戶線程讀取用戶緩沖區的數據，完成后續的業務操作

相對于同步IO，異步IO不是順序執行。

• 用戶進程進行aio_read系統調用之后，無論內核數據是否準備好，都會直接返回給用戶進程，然后用戶態進程可以去做別的事情。

等到數據準備好了，內核直接復制數據給進程，然后從內核向進程發送通知。

對比信號驅動IO，異步IO的主要區別在于：

• 信號驅動由內核告訴我們何時可以開始一個IO操作(數據在內核緩沖區中)，而異步IO則由內核通知IO操作何時已經完成(數據已經在用戶空間中)。

異步IO又叫做事件驅動IO，在Unix中，為異步方式訪問文件定義了一套庫函數，定義了AIO的一系列接口。

• 使用aio_read或者aio_write發起異步IO操作，使用aio_error檢查正在運行的IO操作的狀態。

目前Linux中AIO的內核實現只對文件IO有效，如果要實現真正的AIO，需要用戶自己來實現。

目前有很多開源的異步IO庫，例如libevent、libev、libuv。

Java網絡IO模型

BIO

BIO是一個典型的網絡編程模型，是通常我們實現一個服務端程序的方法，對應Linux內核的同步阻塞IO模型，發送數據和接收數據的過程如下所示：

步驟如下：

• 主線程accept請求
• 請求到達，創建新的線程來處理這個套接字，完成對客戶端的響應
• 主線程繼續accept下一個請求

服務端處理偽代碼如下所示：

這是經典的一個連接對應一個線程的模型，之所以使用多線程，主要原因在于socket.accept()、socket.read()、socket.write()三個主要函數都是同步阻塞的。

當一個連接在處理I/O的時候，系統是阻塞的，如果是單線程的話必然就阻塞，但CPU是被釋放出來的，開啟多線程，就可以讓CPU去處理更多的事情。

其實這也是所有使用多線程的本質：

利用多核，當I/O阻塞時，但CPU空閑的時候，可以利用多線程使用CPU資源。

當面對十萬甚至百萬級連接的時候，傳統的BIO模型是無能為力的。

隨著移動端應用的興起和各種網絡游戲的盛行，百萬級長連接日趨普遍，此時，必然需要一種更高效的I/O處理模型。

NIO

JDK1.4開始引入了NIO類庫，主要是使用Selector多路復用器來實現。

Selector在Linux等主流操作系統上是通過IO復用Epoll實現的。

NIO的實現流程，類似于Select：

• 創建ServerSocketChannel監聽客戶端連接并綁定監聽端口，設置為非阻塞模式
• 創建Reactor線程，創建多路復用器(Selector)并啟動線程
• 將ServerSocketChannel注冊到Reactor線程的Selector上，監聽Accept事件
• Selector在線程run方法中無線循環輪詢準備就緒的Key
• Selector監聽到新的客戶端接入，處理新的請求，完成TCP三次握手，建立物理連接
• 將新的客戶端連接注冊到Selector上，監聽讀操作，讀取客戶端發送的網絡消息
• 客戶端發送的數據就緒則讀取客戶端請求，進行處理

簡單處理模型是用一個單線程死循環選擇就緒的事件，會執行系統調用(Linux 2.6之前是Select、Poll，2.6之后是Epoll，Windows是IOCP)，還會阻塞的等待新事件的到來。

新事件到來的時候，會在Selector上注冊標記位，標示可讀、可寫或者有連接到來，簡單處理模型的偽代碼如下所示：

NIO由原來的阻塞讀寫(占用線程)變成了單線程輪詢事件，找到可以進行讀寫的網絡描述符進行讀寫。

除了事件的輪詢是阻塞的(沒有可干的事情必須要阻塞)，剩余的I/O操作都是純CPU操作，沒有必要開啟多線程。

并且由于線程的節約，連接數大的時候因為線程切換帶來的問題也隨之解決，進而為處理海量連接提供了可能。

AIO

JDK1.7引入NIO2.0，提供了異步文件通道和異步套接字通道的實現。

• 其底層在Windows上是通過IOCP實現，在Linux上是通過IO復用Epoll來模擬實現的。

在JAVA NIO框架中，Selector它負責代替應用查詢中所有已注冊的通道到操作系統中進行IO事件輪詢、管理當前注冊的通道集合，定位發生事件的通道等操作。

但是在JAVA AIO框架中，由于應用程序不是輪詢方式，而是訂閱-通知方式，所以不再需要Selector(選擇器)了，改由Channel通道直接到操作系統注冊監聽 。

JAVA AIO框架中，只實現了兩種網絡IO通道：

• AsynchronousServerSocketChannel(服務器監聽通道)
• AsynchronousSocketChannel(Socket套接字通道)。

具體過程如下所示：

• 創建AsynchronousServerSocketChannel，綁定監聽端口
• 調用AsynchronousServerSocketChannel的accpet方法，傳入自己實現的CompletionHandler，包括上一步，都是非阻塞的
• 連接傳入，回調CompletionHandler的completed方法，在里面，調用AsynchronousSocketChannel的read方法，傳入負責處理數據的CompletionHandler
• 數據就緒，觸發負責處理數據的CompletionHandler的completed方法，繼續做下一步處理即可
• 寫入操作類似，也需要傳入CompletionHandler