netty
BIO的缺陷
-
一個socket由一個線程處理，大量socket引起創建大量線程。
-
數據讀寫是以字節流爲單位，效率不高
NIO
- 線程切換效率:NIO編程模型中，新來一個連接不再創建一個新的線程，而是可以把這條連接直接綁定到某個固定的線程，然後這條連接所有的讀寫都由這個線程來負責。一條連接來了之後，現在不創建一個while死循環去監聽是否有數據可讀了，而是直接把這條連接註冊到selector上，然後，通過檢查這個selector，就可以批量監測出有數據可讀的連接，進而讀取數據。
- IO讀寫單位:IO模型中，每次都是從操作系統底層一個字節一個字節地讀取數據，而NIO維護一個緩衝區，每次可以從這個緩衝區裏面讀取一塊的數據，
Netty的優勢:
- 針對多種傳輸類型的統一接口 - 阻塞和非阻塞
- 簡單但更強大的線程模型
- 真正的無連接的數據報套接字支持
- 鏈接邏輯支持複用
Netty的構成
Channel 是 NIO 基本的結構。它代表了一個用於連接到實體如硬件設備、文件、網絡套接字或程序組件,能夠執行一個或多個不同的 I/O 操作（例如讀或寫）的開放連接。
callback (回調) 是一個簡單的方法,提供給另一種方法作爲引用,這樣後者就可以在某個合適的時間調用前者。這種技術被廣泛使用在各種編程的情況下,最常見的方法之一通知給其他人操作已完成。(一些handler)
Future 提供了另外一種通知應用操作已經完成的方式。這個對象作爲一個異步操作結果的佔位符,它將在將來的某個時候完成並提供結果。JDK 附帶接口 java.util.concurrent.Future ,但所提供的實現只允許您手動檢查操作是否完成或阻塞了。這是很麻煩的，所以 Netty 提供自己了的實現,ChannelFuture,用於在執行異步操作時使用。
Netty架構模型的組件總覽
客戶端連接服務器，是由bossGroup建立連接。建立連接後，客戶端往服務器發送數據由workGroup執行pipeline中一系列handler進行業務處理。
BossGroup
主Reactor的線程池，負責處理建立連接
WorkerGroup
從Reactor的線程池，負責處理客戶端的其他事件如讀、寫，調用相應的handler
認識Netty的ChannelHandler 和 ChannelPipeline
ChannelPipeline 就是 ChannelHandler 鏈的容器。
當 ChannelHandler 被添加到的 ChannelPipeline 它得到一個 ChannelHandlerContext，它代表一個 ChannelHandler 和 ChannelPipeline 之間的“綁定”。它通常是安全保存對此對象的引用，除了當協議中的使用的是不面向連接（例如，UDP）。而該對象可以被用來獲得 底層 Channel,它主要是用來寫出站數據。
一個Channel包含了一個ChannelPipeline，而ChannelPipeline中又維護了一個由ChannelHandlerContext組成的雙向鏈表，並且每個ChannelHandlerContext中又關聯着一個ChannelHandler。入站事件和出站事件在一個雙向鏈表中，入站事件會從鏈表head往後傳遞到最後一個入站的handler，出戰事件會從鏈表tail往前傳遞到最前一個出站的handler，兩類型的handler互不干擾。