聊聊日常開發中的BIO、NIO、AIO。
BIO、NIO是Java常見面試題。很多小夥伴在網絡程式設計中經常會遇到的概念。如果沒有涉及到網絡程式設計或者是做架構，基本上也不會接觸的到。但是隻要談到IO大家就比較熟悉了。
總的來說就是輸入輸出，API的請求，組建之間的通信，通路的應用程式，應用程式通路資料庫緩存全是I0。在整個的服務端請求的過程中，IO可以說每個地方都有。
說到IO不得不說兩個常見的IO模型了，一個是BIO，一個就是NIO，當然後面還有AIO。這其實也是屬于NIO的一個範疇，它是基于NIO做了一個更新。
BIO是阻塞I0，是比較傳統的網絡IO模型。在BIO中的伺服器跟用戶端都會阻塞，早期的像tomcat中接收到。比如web浏覽器發送的請求，就會在web伺服器就會new一個線程來處理請求。
為什麼說它會阻塞？因為在請求的整個的過程中，伺服器還是用戶端，就會一直等待整個請求，完成之後才能夠繼續執行下一步的操作。是以在整個的過程中它就是一個阻塞的狀态。
這樣就會引來一系列的問題。比如說請求越多服務端啟用的線程也會越來越多。很多的線程如果有并發的狀态下面，就會處于一種阻塞的狀态。如果超過一定的門檻值，可能就會導緻整個的服務端請求逾時，或者是整個應用的卡死。是以後來在JDK1.4就引入了NIO。
NIO通過引入像task、channel、buffer還有一些新的概念，來改善傳統的IO的工作模式。
在NIO中解決最大的問題就是它的阻塞問題。服務端用戶端是通過等待io事件的發生而不是像BIO那樣直接阻塞對吧？
當然請求進來的時候是先會讓請求進入叫做buffer的緩沖區，然後通過陌陌來判斷應該複用哪個線程。有需要處理的事件發生時伺服器或者用戶端才會進行相應的處理，而不是每次請求進來都先去new一個線程。這種優化更多的是依賴于多路複用的方式來提高了并發處理的能力。
AIO就是異步I0了，這個是在JDK1.7引入的新特性。AIO相較于NIO來講更加強調了I0在異步處理的能力。服務端和用戶端發送了IO請求後不需要等待結果的傳回，而是繼續進行其他的操作。當IO操作完成之後系統會通知使用者進行後續的處理，這個就是相當于一種回調的處理方式。
這種一步的處理方式當然性能也是最好的，因為它不需要等待處理結果而直接去進行了處理的傳回。在實際的應用場景中怎麼去選擇IO模型？BIO開銷太大了，是以它其實用的并不是很多。當然早期的有一些應用程式也可以結合線程池來做些優化，其實也是可以的。
目前大部分的場景還是用的NIO可以處理大量的并發請求，常見的就是各種IM聊天元件基于netty對吧？其實本質也是基于NIO，還有像Tomcat預設的也都是采用了NIO的IQ模式。
本期的視訊就這些了，如果您對本期的内容有任何疑問歡迎大家在評論區給我留言，謝謝大家！
