跟閃電俠學Netty：Netty 即時聊天實戰與底層原理

基本上寫了個大概，要深入還是需要看一遍源碼，自己調調看

一本比較好的netty入門資料

通俗易懂，配上關鍵代碼講解，一目瞭然，對netty的基礎使用有了一定的瞭解，結合實踐，相信一定可以很快的熟練使用

首先剛開始NettyClient 源碼中的connect方法就因爲retry不是最終變量報錯了 作爲一本已經出版的書籍 源代碼沒有普適性 已經沒有想跟着敲下去想法了

完全是 Netty api 介紹 ，和網絡編程相關的底層原理基本沒有

在傳統的IO模型中，每個連接創建成功之後都需要由一個線程來維護，每個線程都包含一個while死循環，那麼1萬個連接對應1萬個線程，繼而有1萬個while死循環，這就帶來如下幾個問題：1.線程資源受限：線程是操作系統中非常寶貴的資源，同一時刻有大量的線程處於阻塞狀態，是非常嚴重的資源浪費，操作系統耗不起。2.線程切換效率低下：單機CPU核數固定，線程爆炸之後操作系統頻繁進行線程切換，應用性能急劇下降。3.除了以上兩個問題，在IO編程中，我們看到數據讀寫是以字節流爲單位的。 爲了解決這3個問題，JDK在1.4版本之後提出了NIO。 ◆ 而在NIO模型中，這麼多while死循環轉換爲一個死循環，這個死循環由一個線程控制，那麼NIO又是如何做到一個線程一個while死循環就能監測1萬個連接是否有數據可讀的呢？ ◆ 這就是NIO模型中Selector的作用，一個連接來了之後，不會創建一個while死循環去監聽是否有數據可讀，而是直接把這條連接註冊到Selector上。 ◆ IO讀寫是面向流的，一次性只能從流中讀取一字節或者多字節，並且讀完之後流無法再讀取，需要自己緩存數據。而NIO的讀寫是面向Buffer的，可以隨意讀取裏面任何字節數據，不需要自己緩存數據，只需要移動讀寫指針即可。 我們還是先對照NIO來解釋一下核心思路。1.NIO模型中通常會有兩個線程，每個線程都綁定一個輪詢器Selector。在這個例子中，serverSelector負責輪詢是否有新連接，clientSelector負責輪詢連接是否有數據可讀。2.服務端監測到新連接之後，不再創建一個新線程，而是直接將新連接綁定到clientSelector上，這樣就不用IO模型中的1萬個while循環死等。3.clientSelector被一個while死循環包裹着，如果在某一時刻有多個連接有數據可讀，那麼通過clientSelector.select(1)方法可以輪詢出來，進而批量處理。4.數據的讀寫面向Buffer。 總之，強烈不建議直接基於JDK原生NIO來進行網絡開發，下面是筆者總結的原因。1.JDK的NIO編程需要了解很多概念，編程複雜，對NIO入門非常不友好，編程模型不友好，ByteBuffer的API簡直“反人類”。2.對NIO編程來說，一個比較合適的線程模型能充分發揮它的優勢，而JDK沒有實現，需要自己實現，就連簡單的自定義協議拆包都要自己實現。3.JDK的NIO底層由Epoll實現，該實現飽受詬病的空輪詢Bug會導致CPU佔用率飆升至100%。4.項目龐大之後，自行實現的NIO很容易出現各類Bug，維護成本較高，上面這些代碼筆者都不能保證沒有Bug。 下面是筆者總結的使用Netty而不使用JDK原生NIO的原因。1.使用JDK原生NIO需要了解太多概念，編程複雜，一不小心就Bug橫飛。2.Netty底層IO模型隨意切換，而這一切只需要做微小的改動，改改參數，Netty可以直接從NIO模型變身爲IO模型。3.Netty自帶的拆包/粘包、異常檢測等機制讓你從NIO的繁重細節中脫離出來，只需要關心業務邏輯即可。4.Netty解決了JDK很多包括空輪詢在內的Bug。5.Netty底層對線程、Selector做了很多細小的優化，精心設計的Reactor線程模型可以做到非常高效的併發處理。6.自帶各種協議棧，讓你處理任何一種通用協議都幾乎不用親自動手。7.Netty社區活躍，遇到問題隨時郵件列表或者Issue。8.Netty已經歷各大RPC框架、消息中間件、分佈式通信中間件線上的廣泛驗證，健壯性無比強大。

很一般，基本就是api的使用講解。

由淺入深，結合實際案例，一步一步帶領讀者瞭解並使用 netty，後面又深入分析了 netty 的整體架構和源碼，讀完整體感覺是：不會覺得太喫力，也不會覺得過於簡單，適合入門者，也適合想要深入學習的。對於想學習、使用 netty 的讀者來說，這是一本不可多得的好書，

難以置信一本出版書籍的代碼錯誤百出，豆瓣評分9.7你也是敢刷

在學城找到了系列文章，目前看完了前7講。對入門者來說挺友好的。