首先來舉個例子說明吧，假設你想吃一份蓋飯：
同步阻塞：你到飯館點餐，然後在那等著，還要一邊喊：好了沒啊！
同步非阻塞：在飯館點完餐，就去遛狗了。不過溜一會兒，就回飯館喊一聲：好了沒啊！
非同步阻塞：遛狗的時候，接到飯館電話，說飯做好了，讓您親自去拿。
非同步非阻塞：飯館打電話說，我們知道您的位置，一會給你送過來，安心遛狗就可以了。
一、BIO
同步並阻塞，伺服器實現模式為一個連線一個執行緒，即客戶端有連線請求時伺服器端就需要啟動一個執行緒進行處理，如果這個連線不做任何事情會造成不必要的執行緒開銷，當然可以通過執行緒池機制改善。
二、NIO
同步非阻塞，伺服器實現模式為一個請求一個執行緒，即客戶端傳送的連線請求都會註冊到多路複用器上，多路複用器輪詢到連線有I/O請求時才啟動一個執行緒進行處理。
NIO本身是基於事件驅動思想來完成的，其主要想解決的是BIO的大併發問題： 在使用同步I/O的網路應用中，如果要同時處理多個客戶端請求，或是在客戶端要同時和多個伺服器進行通訊，就必須使用多執行緒來處理。也就是說，將每一個客戶端請求分配給一個執行緒來單獨處理。這樣做雖然可以達到我們的要求，但同時又會帶來另外一個問題。由於每建立一個執行緒，就要為這個執行緒分配一定的記憶體空間（也叫工作儲存器），而且作業系統本身也對執行緒的總數有一定的限制。如果客戶端的請求過多，服務端程式可能會因為不堪重負而拒絕客戶端的請求，甚至伺服器可能會因此而癱瘓。
NIO基於Reactor，當socket有流可讀或可寫入socket時，作業系統會相應的通知引用程式進行處理，應用再將流讀取到緩衝區或寫入作業系統。 也就是說，這個時候，已經不是一個連線就要對應一個處理執行緒了，而是有效的請求，對應一個執行緒，當連線沒有資料時，是沒有工作執行緒來處理的。
BIO與NIO一個比較重要的不同，是我們使用BIO的時候往往會引入多執行緒，每個連線一個單獨的執行緒；而NIO則是使用單執行緒或者只使用少量的多執行緒，每個連線共用一個執行緒。IO的最重要的地方是當一個連線建立後，不需要對應一個執行緒，這個連線會被註冊到多路複用器上面，所以所有的連線只需要一個執行緒就可以搞定，當這個執行緒中的多路複用器進行輪詢的時候，發現連線上有請求的話，才開啟一個執行緒進行處理，也就是一個請求一個執行緒模式。
在NIO的處理方式中，當一個請求來的話，開啟執行緒進行處理，可能會等待後端應用的資源(JDBC連線等)，其實這個執行緒就被阻塞了，當併發上來的話，還是會有BIO一樣的問題。
三、AIO
與NIO不同，當進行讀寫操作時，只須直接呼叫API的read或write方法即可。這兩種方法均為非同步的，對於讀操作而言，當有流可讀取時，作業系統會將可讀的流傳入read方法的緩衝區，並通知應用程式；對於寫操作而言，當作業系統將write方法傳遞的流寫入完畢時，作業系統主動通知應用程式。 即可以理解為，read/write方法都是非同步的，完成後會主動呼叫回撥函式。 在JDK1.7中，這部分內容被稱作NIO.2，主要在java.nio.channels包下增加了下面四個非同步通道：
- AsynchronousSocketChannel
- AsynchronousServerSocketChannel
- AsynchronousFileChannel
- AsynchronousDatagramChannel
其中的read/write方法，會返回一個帶回撥函式的物件，當執行完讀取/寫入操作後，直接呼叫回撥函式。
BIO、NIO、AIO適用場景分析:
•BIO方式適用於連線數目比較小且固定的架構，這種方式對伺服器資源要求比較高，併發侷限於應用中，JDK1.4以前的唯一選擇，但程式直觀簡單易理解。
•NIO方式適用於連線數目多且連線比較短（輕操作）的架構，比如聊天伺服器，併發侷限於應用中，程式設計比較複雜，JDK1.4開始支援。
•AIO方式使用於連線數目多且連線比較長（重操作）的架構，比如相簿伺服器，充分呼叫OS參與併發操作，程式設計比較複雜，JDK7開始支援。
