三分鐘秒懂BIO/NIO/AIO區別？
- 2020 年 8 月 12 日
- 筆記
首先來舉個例子說明吧，假設你想吃一份蓋飯：
同步阻塞：你到飯館點餐，然後在那等着，還要一邊喊：好了沒啊！
同步非阻塞：在飯館點完餐，就去遛狗了。不過溜一會兒，就回飯館喊一聲：好了沒啊！
異步阻塞：遛狗的時候，接到飯館電話，說飯做好了，讓您親自去拿。
異步非阻塞：飯館打電話說，我們知道您的位置，一會給你送過來，安心遛狗就可以了。
一、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開始支持。
