大神是如何理解Netty裡面的構件的？

最美的不是下雨天，是曾與你躲過雨的屋檐——方文山

人類的大腦能夠發展到現在的發達情況，還是因為善於開發，懂得如何開發。正如一直被視為網路編程也亦如此，很多概念非常的抽象，但是善於運用大腦的機制是很容易達到理解並且運用的效果。比如Netty這個編程界的里程碑，很多人都說如果你對java的源碼反覆的閱讀，達到一定的瓶頸，甚至厭倦的情況，請你一定要好好看看Netty的源碼，當然網上很多推薦看的書籍也是甚多，但是本人覺得還行自行從git下載最新的源碼，通讀一遍然後自建理解體系，再通過一些實戰的觀點來有所取捨的了解Netty這個框架會有比較不錯的效果。

正題說到的Netty框架的使用，在閱讀本文的時候建議15分鐘，主要理解過程為主，如果你要想了解Netty你應該是對java有一定的了解，以及有自己深刻的體會，每次當java遇到技術瓶頸要被人淘汰，都出現了大神級別的框架來給人們使用。比如Netty，Spring，等等。

現在來分幾個模塊來了解Netty，從組建的整體把握，再到邏輯處理，然後是應用領域。

組件的整體把握。

提到這裡不得鏈接一張我自己歸納的理解圖，如果有好用的3D工具，小夥伴也可以推薦。這裡大部分圖片來自ImportNew

圖中所示，這是Reactor模型，而ThreadPool是對傳統的Netty的擴展，多路復用的傳遞到了多個read對象以及send對象，每個大圈都為一個Channel，而每個Channel裡面會註冊n個pipeline，而多個pipeline會共享一個chandler，而多個chandler也可以服務多個pipeline，而資源分配方面就是由我們的cpu分派給到各自的thread，而thread就是我們的evenLoop，evenLoop會承接這些Channel的處理，比如我們一個I/O過來需要對請求進行decode，然後從後台邏輯，訪問磁碟，獲取數據返回到pipeline再進行encode，響應個client，這個過程就是使用到了evenLoop來分配資源處理，這個就是為什麼解決了我們的傳統的socket阻塞的通病，這樣的設計無需等待read對象，write對象的返回才能處理下個邏輯，而是通過多個evenLoop註冊到我們的channel，而這些evenLoop會在沒有自己需要運行的隊列任務的時候就會通過channelHandlerContex來分配執行已經註冊的channel裡面的handler邏輯，這樣的設計就大大的減少的thread的資源分配的浪費以及消耗。

邏輯處理

提到邏輯處理就是肯定是我們頂層設計的EvenExecutorGroup，這個是擴展了java.util.concurrent包的Executor介面，為了能否使用到executor這個對象，分別出現了子介面SingleThreadEvenExecutor，以及其擴展的子介面，也就是我們最常用的介面EvenLoopGroup，其子類為我們的資源分配者EvenLoop，他有個方法就是返回父類引用 EvenLoopGroup parent().這也是為了簡化整個框架來出發的，很多時候我們的程序如果出現大量配置一樣的對象的對象的時候可以實現Cloneable這個介面。

我們的ChannelHandlerContext的作用做了個協調各種handler對I/O的操作。

實戰應用

對於這部分的內容後續會更新，畢竟設計到工作上的一些內容。

最後配個圖，有疑問可以留言，儘快回復。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！