在讀《Netty權威指南》時，關於I/O模型的描述，個人感覺還是不是很容易理解。這裏想用通俗一點的方式表達清楚。
關於I/O模型的發展這裏不再描述，簡要說明現在的幾種I/O模型：
根據UNIX網絡編程對I/O模型的分類，UNIX提供了5中I/O模型，分別如下：
1. 阻塞I/O模型
2. 非阻塞I/O模型
3. I/O複用模型
4. 信號驅動I/O模型
5. 異步I/O模型
具體的描述直接上書中的截圖：
怎麼理解呢？看文字描述，阻塞I/O模型，在套接字建立連接後，系統分配了一個進程用於接受這個套接字接口的信息，即數據，數據先從接口傳入系統內核（我理解系統的內存區域），然後複製到應用程序的緩存區（用戶空間）中，這個過程一直是阻塞的，即系統分配的進程一直掛起並等待這一過程。
打個比方：計算機相當於一個公司，分配的socket相當於一部電話，系統分配的進程（應用程序的線程）相當於接電話的員工，公司的日常工作時，接到電話會有人來送貨，關鍵是從接到電話，到貨物到達公司的院子（內核），這段時間也要保持電話連接，然後貨物從公司的院子（內核）送到對應的倉庫中（用戶空間），在接到電話到貨物送到倉庫中這一時間段內，這位員工需要全程看護（阻塞），不能幹其它事情。
這樣看來，如果系統能養100個員工，那麼最多一次只能處理100個送貨的請求，而且貨物如果比較多，員工會一直阻塞在那裏，浪費了公司的人力資源（系統資源）
再來看看非阻塞I/O模型：
根據上面的例子，接下來這個是不是好理解一些了？
用阻塞式I/O的模式工作了一段時間，公司覺得這樣處理效率很低，做了以下的優化：
員工接到送貨電話（連接），知道將要有貨物過來，就隔一段時間跑出去看一眼就沒有貨物到院子（內核），如果沒有，就回去繼續工作，有的話再監護（阻塞）貨物送到倉庫（用戶空間）的操作。
這樣一來，在數據沒有完全到達之前，進程就不用一直阻塞在那裏了。
下面是第三種模型，I/O複用模型：
非阻塞式I/O的效率還是太低了，一個員工在收到送貨請求以後才能開始另外一個送貨請求。雖然貨物沒到院子之前他可以去幹別的什麼工作。
看這個圖可以發現，在數據就緒（貨物到達院子）的階段，進程又是阻塞的了，那這個模型和阻塞I/O有什麼區別呢？I/O複用，即一個線程可以同時處理多個連接，即一個員工，可以同時接收好幾個送貨的請求，接到請求後，他不會回去處理別的事情（阻塞），而是不停的查看哪個客戶端的貨物（數據）過來了（select/poll），然後在監護這些貨物送到倉庫中。還有另外一種工作方式，公司在院子裏安裝了一個門鈴（事件通知），當貨物送到院子裏的時候，門鈴會通知員工有貨物到達（epoll）。
下面是信號驅動I/O模型：
信號驅動I/O模型，可以理解爲，公司專門請了一個跑腿的，負責看管院子裏是否有貨物過來，員工接到電話後告訴跑腿的，xx貨物來的時候告訴我一聲，然後該幹嘛幹嘛去了，貨物來的時候跑腿的就去找該員工，然後員工再繼續監護這些貨物送到倉庫。
信號驅動I/O模型，讓應用程序的線程再一次減少了阻塞時間，但是數據從內核到用戶空間這段時間仍然是阻塞的，當然阻塞的時間相對來說大大減少了。
最後是異步I/O模型：
從描述來看，這些員工監護貨物從院子到倉庫這段阻塞時間都減少了，他接到電話，直接告訴跑腿的要放到xx倉庫，放好了再通知我，然後員工幾乎不再有I/O的阻塞時間了。
寫到這，以上的理解或許對或許有些偏差，希望大家能夠給與指正。