首先我們來定義流的概念，一個流可以是文件，socket，pipe等等可以進行I/O操作的內核對象。
不管是文件，還是套接字，還是管道，我們都可以把他們看作流。
之後我們來討論I/O的操作，通過read，我們可以從流中讀入數據；通過write，我們可以往流寫入數據。現在假定一個情形，我們需要從流中讀數據，但是流中還沒有數據，（典型的例子為，客戶端要從socket讀如數據，但是服務器還沒有把數據傳回來），這時候該怎麼辦？
阻塞：阻塞是個什麼概念呢？比如某個時候你在等快遞，但是你不知道快遞什麼時候過來，而且你沒有別的事可以干（或者說接下來的事要等快遞來了才能做）；那麼你可以去睡覺了，因為你知道快遞把貨送來時一定會給你打個電話（假定一定能叫醒你）。
非阻塞忙輪詢：接著上面等快遞的例子，如果用忙輪詢的方法，那麼你需要知道快遞員的手機號，然後每分鐘給他掛個電話：“你到了沒？”
很明顯一般人不會用第二種做法，不僅顯很無腦，浪費話費不說，還占用了快遞員大量的時間。
大部分程序也不會用第二種做法，因為第一種方法經濟而簡單，經濟是指消耗很少的CPU時間，如果線程睡眠了，就掉出了系統的調度隊列，暫時不會去瓜分CPU寶貴的時間片了。
為了了解阻塞是如何進行的，我們來討論緩沖區，以及內核緩沖區，最終把I/O事件解釋清楚。緩沖區的引入是為了減少頻繁I/O操作而引起頻繁的系統調用（你知道它很慢的），當你操作一個流時，更多的是以緩沖區為單位進行操作，這是相對於用戶空間而言。對於內核來說，也需要緩沖區。
假設有一個管道，進程A為管道的寫入方，Ｂ為管道的讀出方。
假設一開始內核緩沖區是空的，B作為讀出方，被阻塞著。然後首先A往管道寫入，這時候內核緩沖區由空的狀態變到非空狀態，內核就會產生一個事件告訴Ｂ該醒來了，這個事件姑且稱之為“緩沖區非空”。
但是“緩沖區非空”事件通知B後，B卻還沒有讀出數據；且內核許諾了不能把寫入管道中的數據丟掉這個時候，Ａ寫入的數據會滯留在內核緩沖區中，如果內核也緩沖區滿了，B仍未開始讀數據，最終內核緩沖區會被填滿，這個時候會產生一個I/O事件，告訴進程A，你該等等（阻塞）了，我們把這個事件定義為“緩沖區滿”。
假設後來Ｂ終於開始讀數據了，於是內核的緩沖區空了出來，這時候內核會告訴A，內核緩沖區有空位了，你可以從長眠中醒來了，繼續寫數據了，我們把這個事件叫做“緩沖區非滿”
也許事件Y1已經通知了A，但是A也沒有數據寫入了，而Ｂ繼續讀出數據，知道內核緩沖區空了。這個時候內核就告訴B，你需要阻塞了！，我們把這個時間定為“緩沖區空”。
這四個情形涵蓋了四個I/O事件，緩沖區滿，緩沖區空，緩沖區非空，緩沖區非滿（注都是說的內核緩沖區，且這四個術語都是我生造的，僅為解釋其原理而造）。這四個I/O事件是進行阻塞同步的根本。（如果不能理解“同步”是什麼概念，請學習操作系統的鎖，信號量，條件變量等任務同步方面的相關知識）。
然後我們來說說阻塞I/O的缺點。但是阻塞I/O模式下，一個線程只能處理一個流的I/O事件。如果想要同時處理多個流，要麼多進程(fork)，要麼多線程(pthread_create)，很不幸這兩種方法效率都不高。
於是再來考慮非阻塞忙輪詢的I/O方式，我們發現我們可以同時處理多個流了（把一個流從阻塞模式切換到非阻塞模式再此不予討論）：
while true {
for i in stream[]; {
if i has data
read until unavailable
}
}
我們只要不停的把所有流從頭到尾問一遍，又從頭開始。這樣就可以處理多個流了，但這樣的做法顯然不好，因為如果所有的流都沒有數據，那麼只會白白浪費CPU。這裡要補充一點，阻塞模式下，內核對於I/O事件的處理是阻塞或者喚醒，而非阻塞模式下則把I/O事件交給其他對象（後文介紹的select以及epoll）處理甚至直接忽略。
