一、我們先來看BIO的問題：

1 ?沒有數據緩沖區，I/O性能存在問題；

2 ?沒有C或C++中的Channel概念，只有輸入和輸出流；

3 ?通常會導致通信線程被長時間阻塞；

4 ?支持的字符集有限，硬件可移植性不好。

阻塞I/O模型：系統調用到數據包到達且被復制到應用進程的緩沖區中或者發生錯誤時才返回，在此期間一直會等待。

非阻塞I/O模型：輪詢檢查緩沖區有無數據的狀態。

I/O復用模型：Linux提供select/poll，偵測多個fd是否處于就緒狀態。同時還提供了一個epoll系統調用，一個基于事件驅動方式代替順序掃描，因此性能更高。

信號驅動模型：通過信號回調通知應用程序調用recvfrom來讀取數據

異步I/O：和信號驅動I/O區別在于異步I/O模型由內核通知我們I/O操作何時已經完成。

二、I/O多路復用

優勢：系統開銷小，不需要創建新的額外進程或者線程，不需要維護進程和線程的運行，降低了系統維護工作量，節省系統資源。

應用場景：server同時處理多個處于監聽狀態或者多個連接狀態的套接字；

server需要同時處理多種網絡協議的套接字。

三、傳統BIO編程

下面先看下BIO通信模型圖

首先有個Acceptor，負責監聽多個客戶端的連接，接收到連接請求后為每個客戶端創建一個新的線程進行鏈路處理，處理完成后，通過輸出流給客戶端發送響應，這就是經典的請求-應答模型。

該模型最大的問題就是缺乏彈性伸縮能力，當客戶端并發訪問量增加后，服務端的線程個數和客戶端并發訪問數呈1:1的正比關系，由于線程是Java虛擬機寶貴的系統資源，當線程數膨脹后，系統性能將急劇下降，隨著并發量持續增大，系統會發生線程堆棧溢出、創建新線程失敗等問題，并最終導致進程宕機或者僵死，不能對外提供服務。

為了改進一線程一連接模型，后來又演進了一種通過線程池或者消息隊列實現1個或者多個線程處理N個客戶端的模型，由于它的底層通信機制依然使用同步阻塞I/O，所以被稱為“偽異步”。

四、偽異步I/O編程

偽異步I/O通信模型圖

偽異步I/O弊端分析

首先，當對Socket的輸入流進行讀取操作的時候，它會一直阻塞下去，直到發生如下三種事件：

有數據可讀；

可用數據已經讀取完畢；

發生空指針或者I/O異常。

這就意味著如果發送請求或者應答消息比較慢，或者網絡傳輸較慢時，讀取輸入流一方通信線程就將長時間阻塞，在此期間，其他接入消息只能在消息隊列中排隊。

因此，偽異步I/O實際上僅僅是對之前I/O線程模型的一個簡單優化，它無法從根本上解決同步I/O導致的通信線程阻塞問題。

OK，到這里，阻塞I/O的相關知識就講解完畢，下節開始講NIO編程的相關知識和原理。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的java 伪异步 netty,Netty（一） - 不死的达芬奇的个人空间 - OSCHINA - 中文开源技术交流社区...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。