netty項目源碼

Ⅰ Netty源碼探究1：事件驅動原理

Netty源碼探究1：事件驅動原理

Netty借鑒了Reactor設計模式，這是一種事件處理模式，用於管理並發服務請求。在模式中，服務處理器對請求進行I/O多路復用，並同步分發給相應的請求處理器。Netty的核心內容是Reactor，因此深入分析其在Netty中的應用至關重要。Netty吸收了前人優秀經驗，構建出這款優秀的技術框架。

在Reactor設計模式中，Demultiplexer和Dispatcher是關鍵概念。Netty中的Demultiplexer是如何實現的？答案在於其Server端的架構設計。Netty通過Bootstrap（ServerBootstrap也適用）來構建Server，其中bind方法是啟動Reactor運行的關鍵。在bind方法中，Netty創建並注冊Channel到EventLoopGroup，從而實現Demultiplexer的功能。

Netty中的Channel與JDK中的Channel有何不同？Netty通過NioServerSocketChannel構建Server，其內部封裝了Java NIO的Channel，但Netty的Channel與JDK中的Channel在注冊到Selector時有所不同。Netty中的Channel注冊到NioEventLoop中的Selector上，只關注OP_ACCEPT事件。當客戶端連接時，事件被觸發，Server響應客戶端連接。這涉及NioServerSocketChannel的構造過程和Selector的創建。

Dispatcher在Java NIO中負責事件分發，Netty中如何實現這一功能？在NioEventLoop中，Selector.select()方法配合run()函數，共同實現事件監聽循環。run函數中包含事件狀態機和事件分派邏輯。當有事件到來時，狀態機觸發processSelectedKeys()方法，根據事件類型調用相應處理器進行處理。

Netty中的事件驅動原理最終如何與自定義handler關聯？在NioEventLoop的processSelectedKey()方法中，事件處理邏輯與Channel.Unsafe介面相關聯。Channel.Unsafe介面用於封裝Socket的最終操作，Netty通過此介面與業務層Handler建立關聯。通過調用handler的read方法，Netty將事件與業務處理邏輯關聯起來。

總之，Netty通過Reactor設計模式實現了事件驅動原理，藉助Demultiplexer和Dispatcher的機制，實現了對並發請求的高效處理。理解Netty的源碼結構和事件驅動原理，對於深入掌握Netty技術框架至關重要。

Ⅱ Netty 源碼解析 ——— ChannelConfig 和 Attribute

嗯，本文與其說是ChannelConfig、Attribute源碼解析，不如說是對ChannelConfig以及Attribute結構層次的分析。因為這才是它們在Netty中使用到的重要之處。

在 Netty 源碼解析 ——— 服務端啟動流程 (下) 中說過，當我們在構建NioServerSocketChannel的時候同時會構建一個NioServerSocketChannelConfig對象賦值給NioServerSocketChannel的成員變數config。

而這一個NioServerSocketChannelConfig是當前NioServerSocketChannel配置屬性的集合。NioServerSocketChannelConfig主要用於對NioServerSocketChannel相關配置的設置(如，網路的相關參數配置)，比如，配置Channel是否為非阻塞、配置連接超時時間等等。

NioServerSocketChannelConfig其實是一個ChannelConfig實例。ChannelConfig表示為一個Channel相關的配置屬性的集合。所以NioServerSocketChannelConfig就是針對於NioServerSocketChannel的配置屬性的集合。

ChannelConfig是Channel所需的公共配置屬性的集合，如，setAllocator(設置用於channel分配buffer的分配器)。而不同類型的網路傳輸對應的Channel有它們自己特有的配置，因此可以通過擴展ChannelConfig來補充特有的配置，如，ServerSocketChannelConfig是針對基於TCP連接的服務端ServerSocketChannel相關配置屬性的集合，它補充了針對TCP服務端所需的特有配置的設置setBacklog、setReuseAddress、setReceiveBufferSize。

DefaultChannelConfig作為ChannelConfig的默認實現，對ChannelConfig中的配置提供了默認值。

接下來，我們來看一個設置ChannelConfig的流程：
serverBootstrap.option(ChannelOption.SO_REUSEADDR, true);
我們可以在啟動服務端前通過ServerBootstrap來進行相關配置的設置，該選項配置會在Channel初始化時被獲取並設置到Channel中，最終會調用底層ServerSocket.setReuseAddress方法來完成配置的設置。
ServerBootstrap的init()方法：

首先對option和value進行校驗，其實就是進行非空校驗。
然後判斷對應的是哪個常量屬性，並進行相應屬性的設置。如果傳進來的ChannelOption不是已經設定好的常量屬性，則會列印一條警告級別的日誌，告知這是未知的channel option。
Netty提供ChannelOption的一個主要的功能就是讓特定的變數的值給類型化。因為從』ChannelOption<T> option』和』T value』可以看出，我們屬性的值類型T，是取決於ChannelOption的泛型的，也就屬性值類型是由屬性來決定的。

這里，我們可以看到有個ChannelOption類，它允許以類型安全的方式去配置一個ChannelConfig。支持哪一種ChannelOption取決於ChannelConfig的實際的實現並且也可能取決於它所屬的傳輸層的本質。

可見ChannelOption是一個Consant擴展類，Consant是Netty提供的一個單例類，它能安全去通過』==』來進行比較操作。通過ConstantPool進行管理和創建。
常量由一個id和name組成。id：表示分配給常量的唯一數字；name：表示常量的名字。

如上所說，Constant是由ConstantPool來進行管理和創建的，那麼ConstantPool又是個什麼樣的類了？

首先從constants中get這個name對應的常量，如果不存在則調用newConstant()來構建這個常量tempConstant，然後在調用constants.putIfAbsent方法來實現「如果該name沒有存在對應的常量，則插入，否則返回該name所對應的常量。(這整個的過程都是原子性的)」，因此我們是根據putIfAbsent方法的返回來判斷該name對應的常量是否已經存在於constants中的。如果返回為null，則說明當前創建的tempConstant就為name所對應的常量；否則，將putIfAbsent返回的name已經對應的常量值返回。(注意，因為ConcurrentHashMap不會允許value為null的情況，所以我們可以根據putIfAbsent返回為null則代表該name在此之前並未有對應的常量值)

正如我們前面所說的，這個ConstantPool<ChannelOption<Object>> pool(即，ChannelOption常量池)是ChannelOption的一個私有靜態成員屬性，用於管理和創建ChannelOption。

這些定義好的ChannelOption常量都已經存儲數到ChannelOption的常量池(ConstantPool)中了。

注意，ChannelOption本身並不維護選項值的信息，它只是維護選項名字本身。比如，「public static final ChannelOption<Integer> SO_RCVBUF = valueOf("SO_RCVBUF");」👈這只是維護了「SO_RCVBUF」這個選項名字的信息，同時泛型表示選擇值類型，即「SO_RCVBUF」選項值為Integer。

好了，到目前為止，我們對Netty的ChannelOption的設置以及底層的實現已經分析完了，簡單的來說：Netty在初始化Channel時會構建一個ChannelConfig對象，而ChannelConfig是Channel配置屬性的集合。比如，Netty在初始化NioServerSocketChannel的時候同時會構建一個NioServerSocketChannelConfig對象，並將其賦值給NioServerSocketChannel的成員變數config，而這個config(NioServerSocketChannelConfig)維護了NioServerSocketChannel的所有配置屬性。比如，NioServerSocketChannelConfig提供了setConnectTimeoutMillis方法來設置NioServerSocketChannel連接超時的時間。
同時，程序可以通過ServerBootstrap或Boostrap的option(ChannelOption<T> option, T value)方法來實現配置的設置。這里，我們通過ChannelOption來實現配置的設置，ChannelOption中已經將常用的配置項預定義為了常量供我們直接使用，同時ChannelOption的一個主要的功能就是讓特定的變數的值給類型化。因為從』ChannelOption<T> option』和』T value』可以看出，我們屬性的值類型T，是取決於ChannelOption的泛型的，也就屬性值類型是由屬性來決定的。

一個attribute允許存儲一個值的引用。它可以被自動的更新並且是線程安全的。
其實Attribute就是一個屬性對象，這個屬性的名稱為AttributeKey<T> key，而屬性的值為T value。

我們可以通過程序ServerBootstrap或Boostrap的attr方法來設置一個Channel的屬性，如：
serverBootstrap.attr(AttributeKey.valueOf("userID"), UUID.randomUUID().toString());
當Netty底層初始化Channel的時候，就會將我們設置的attribute給設置到Channel中：

如上面所說，Attribute就是一個屬性對象，這個屬性的名稱為AttributeKey<T> key，而屬性的值為T value。
而AttributeKey也是Constant的一個擴展，因此也有一個ConstantPool來管理和創建，這和ChannelOption是類似的。

Channel類本身繼承了AttributeMap類，而AttributeMap它持有多個Attribute，這些Attribute可以通過AttributeKey來訪問的。所以，才可以通過channel.attr(key).set(value)的方式將屬性設置到channel中了(即，這里的attr方法實際上是AttributeMap介面中的方法)。

AttributeKey、Attribute、AttributeMap間的關系：
AttributeMap相對於一個map，AttributeKey相當於map的key，Attribute是一個持有key(AttributeKey)和value的對象。因此在map中我們可以通過AttributeKey key獲取Attribute，從而獲取Attribute中的value(即,屬性值)。

Q：ChannelHandlerContext和Channel都提供了attr方法，那麼它們設置的屬性作用域有什麼不同了？
A：在Netty 4.1版本之前，它們兩設置的屬性作用域確實存在著不同，但從Netty 4.1版本開始，它們兩設置的屬性的作用域已經完全相同了。

若文章有任何錯誤，望大家不吝指教:)

聖思園《精通並發與Netty》