BIO：一請求一應答模型      阻塞同步IO

一個執行緒去監聽客戶端連結，當監聽到客戶端連結時，會為每個客戶端建立一個新的執行緒去進行處理，處理結束，通過輸出流返回應答給客戶端，最後銷燬執行緒。

缺點：由於會每個客戶端請求建立新的執行緒去處理。所以隨著併發量的增加，效率會大大降低。 還有可能出現執行緒堆疊溢位，建立新執行緒失敗等問題。最終會導致無法提供提供服務。

偽非同步IO通訊=BIO+執行緒池    阻塞同步IO

在BIO基礎上增加使用執行緒池管理客戶端請求的執行緒。

當有一個新的客戶端請求時，將客戶端的WebSocket封裝成一個非同步任務。交由執行緒池進行處理。由於執行緒池中可以設定訊息佇列(任務)大小。以及最大執行緒數，所以資源是可控的，無論多少個併發客戶端訪問，都不出現因資源耗盡而造成的down機的情況。

缺點：當大量客戶端接入，併發量很大時，可能會出現執行緒池執行緒阻塞等待。

NIO：非阻塞同步IO

1、緩衝區Buffer：讀資料是從緩衝區讀，寫資料也是寫入緩衝區。所有的資料都是通過緩衝區處理。

2、通道Channel：雙向的，可以讀寫，或同時讀寫。流是單向的，只能讀或寫。

3、多路複用器Selector：Selector一直輪詢Channel。當Channel發生讀寫操作時，該Channel就處於就緒狀態，就會被Selector輪詢出來。通過Selection.key()就可以獲取就緒Channel的集合。之後再進行後續操作。

而由於

AIO：非阻塞非同步IO

1、連線註冊讀寫事件和回撥函式

2、讀寫方法非同步。

3、主動通知程式。

兩種方式獲取結果。

1、java.util.concurrent.Future類來儲存非同步操作的結果，Future get()方法（帶或不帶超時引數）在非同步IO操作完成時獲取其結果。

2、在非同步操作時，傳入回撥的handler

該Handler是java.nio.channels.CompletionHandler介面的實現類。

JDK使用Epoll代替了傳統的Selector實現。而且Epoll沒有最大連結數的限制。可以接入數萬級的客戶端。