摘要：隨著狀態(tài)發(fā)生變化，相應(yīng)的產(chǎn)生。這些被轉(zhuǎn)發(fā)到中的來采取相應(yīng)的操作。當(dāng)收到數(shù)據(jù)或相關(guān)的狀態(tài)改變時(shí)，這些方法被調(diào)用，這些方法和的生命周期密切相關(guān)。主要由一系列組成的。采用的線程模型，在同一個(gè)線程的中處理所有發(fā)生的事。

「博客搬家」  原地址: 簡(jiǎn)書  原發(fā)表時(shí)間: 2017-05-05

學(xué)習(xí)了一段時(shí)間的 Netty，將重點(diǎn)與學(xué)習(xí)心得總結(jié)如下，本文主要總結(jié)ChannelHandler 及 EventLoop 的知識(shí)點(diǎn)和基本用法，本文章節(jié)排序參照《Netty in Action》的章節(jié)排序。

以下內(nèi)容主要參考「并發(fā)編程網(wǎng)」的 《Netty in Action》中文版 以及《Netty in Action》原版圖書，輔助參考 Essential Netty in Action 《Netty 實(shí)戰(zhàn)(精髓)》 以及 Netty 官網(wǎng)的 Netty 4.1 JavaDoc 。

一個(gè) Channel 正常的生命周期如下圖所示。隨著狀態(tài)發(fā)生變化，相應(yīng)的 event 產(chǎn)生。這些 event 被轉(zhuǎn)發(fā)到 ChannelPipeline 中的 ChannelHandler 來采取相應(yīng)的操作。

ChannelHandler 有兩個(gè)重要的子接口：

「ChannelInboundHandler」處理輸入數(shù)據(jù)和所有類型的狀態(tài)變化

「ChannelOutboundHandler」處理輸出數(shù)據(jù)，可以攔截所有操作

下表列出接口 ChannelInboundHandler 的方法。當(dāng)收到數(shù)據(jù)或相關(guān) Channel 的狀態(tài)改變時(shí)，這些方法被調(diào)用，這些方法和Channel的生命周期密切相關(guān)。

輸出的操作和數(shù)據(jù)由 ChannelOutBoundHandler 處理。它的方法可以被 Channel，ChannelPipeline 和 ChannelHandlerContext 調(diào)用，子接口 ChannelOutboundHandler 的主要方法如下：

ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter 這兩個(gè)適配器類分別提供了 ChannelInboundHandler 和 ChannelOutboundHandler 的基本實(shí)現(xiàn)，它們繼承了共同的父接口 ChannelHandler 的方法，擴(kuò)展了抽象類 ChannelHandlerAdapter。

ChannelHandlerAdapter 提供了工具方法 isSharable()。如果類實(shí)現(xiàn)帶 @Sharable 注解，那么這個(gè)方法就會(huì)返回 true，意味著這個(gè)對(duì)象可以被添加到多個(gè) ChannelPipeline 中。

ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter 中的方法調(diào)用相關(guān) ChannelHandlerContext 中的等效方法，因此將事件轉(zhuǎn)發(fā)到管道中的下一個(gè)ChannelHandler。

ChannelPromise 是 ChannelFuture 的子接口

而 ChannelFuture 是不可變對(duì)象

ChannelPromise 定義了可寫的方法，比如 setSuccess(), setFailure()

1. 輸入方向「Inbound」
當(dāng)一個(gè) ChannelInboundHandler 實(shí)現(xiàn)類重寫 channelRead() 方法時(shí)，它要負(fù)責(zé)釋放 ByteBuf 相關(guān)的內(nèi)存?？墒褂?Netty 提供的工具方法：

    ReferenceCountUtil.release(「ByteBuf 的對(duì)象」)

更簡(jiǎn)單的，可使用子類 SimpleChannelInboundHandler ，一條消息在被 ChannelRead0() 讀取后，會(huì)被自動(dòng)釋放資源，此時(shí)任何對(duì)消息的引用都會(huì)變成無效，所以不能保存這些引用待后來使用。

2. 輸出方向「Outbound」
在輸出方向，如果處理一個(gè) write() 操作并且丟棄一條消息（沒有寫入 Channel），就應(yīng)該負(fù)責(zé)釋放這條消息。

@ChannelHandler.Sharable public 
class DiscardOutboundHandler extends ChannelOutboundHandlerAdapter {

@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
    ReferenceCountUtil.release(msg);  //使用 ReferenceCountUtil.release(...) 釋放資源
    promise.setSuccess();  //通知 ChannelPromise 數(shù)據(jù)已經(jīng)被處理
}

如果一個(gè)消息被“消費(fèi)”或者丟棄，沒有送到 ChannelPipeline 中的下一個(gè) ChannelOutboundHandler，用戶就要負(fù)責(zé)調(diào)用 ReferenceCountUtil.release()。如果消息到達(dá)了真正的傳輸層，在它被寫到 Socket 中或者 Channel 關(guān)閉時(shí)，會(huì)被自動(dòng)釋放，用戶不用管。

每個(gè)新創(chuàng)建的 Channel 都會(huì)分配一個(gè)新的 ChannelPipeline，Channel 不可以更換或解除當(dāng)前的 ChannelPipeline，在 Netty 組件的整個(gè)生命周期中這個(gè)關(guān)系是固定的。

一個(gè) ChannelPipeline 可看成是一串 ChannelHandler 實(shí)例，攔截穿過 Channel 的輸入輸出 event。

根據(jù)來源，一個(gè) event 可以被一個(gè) ChannelInboundHandler 或 ChannelOutboundHandler 處理。接下來，通過調(diào)用 ChannelHandlerContext 的方法，event 會(huì)被轉(zhuǎn)發(fā)到下一個(gè)同類型的 handler。

通過 ChannelHandlerContext，一個(gè) handler 可以通知 ChannelPipeline 中的下一個(gè)ChannelHandler，甚至動(dòng)態(tài)改動(dòng)下一個(gè)ChannelHandler 所屬的 ChannelPipeline。

ChannelPipeline 主要由一系列 ChannelHandler 組成的。ChannelPipeline 提供在 ChannelPipeline 中傳送 event 的方法。

ChannelHandlerContext 的一些方法和其他類（Channel 和 ChannelPipeline）的方法名字相似，但是 ChannelHandlerContext 的方法采用了更短的 event 傳遞路程。我們應(yīng)該盡可能利用這一點(diǎn)來實(shí)現(xiàn)最好的性能。

如果你在 Channel 或者 ChannelPipeline 實(shí)例上調(diào)用這些方法，它們的調(diào)用會(huì)穿過整個(gè) pipeline。而在 ChannelHandlerContext 上調(diào)用的同樣的方法，僅僅從當(dāng)前 ChannelHandler 開始，走到 pipeline 中下一個(gè)可以處理這個(gè) event 的 ChannelHandler。

「本節(jié)參考」 第六章 ChannelHandler 和 ChannelPipeline

從池中空閑的線程中選出一個(gè)，分配一個(gè)提交的task「一個(gè)Runnable的實(shí)現(xiàn)」

當(dāng)task完成，線程返回池中，等待復(fù)用「下一次task分配」

EventLoop 始終由一個(gè)線程驅(qū)動(dòng)

一個(gè) EventLoop 可以被指派來服務(wù)多個(gè) Channel

一個(gè) Channel 只擁有一個(gè) EventLoop

task (Runnable或Callable) 可以直接提交到 EventLoop 實(shí)現(xiàn)即刻或者延后執(zhí)行。根據(jù)配置和可用的CPU核，可以創(chuàng)建多個(gè) EventLoop 來優(yōu)化資源利用。

一個(gè) event 的本質(zhì)決定了它將如何被處理；它可能從網(wǎng)絡(luò)協(xié)議棧傳送數(shù)據(jù)到你的應(yīng)用，或者反過來，或者做一些完全不一樣的事情。但是 event 處理邏輯必須足夠通用和靈活，來對(duì)付所有可能的情況。

所以，在 Netty 4，所有的 I/O 操作和 event 都是由分配給 EventLoop 的那一個(gè) Thread 來處理的。Netty 4 采用的線程模型，在同一個(gè)線程的 EventLoop 中處理所有發(fā)生的事。

EventLoopGroup 負(fù)責(zé)分配 EventLoop 到新創(chuàng)建的 Channel

異步實(shí)現(xiàn)只用了很少 EventLoop，這幾個(gè) EventLoop 被所有 Channel 共享

一但 Channel 被指派了一個(gè) EventLoop，在它的整個(gè)生命周期過程中，都會(huì)用這個(gè) EventLoop

為 Channel 的 I/O 和 event 提供服務(wù)的 EventLoop 都包含在一個(gè) EventLoopGroup 中。EventLoop 創(chuàng)建和分配的方式根據(jù)傳輸實(shí)現(xiàn)的不同而有所不同。

異步實(shí)現(xiàn)只用了很少幾個(gè) EventLoop（和它們關(guān)聯(lián)的線程），在目前 Netty 的模型中，這幾個(gè) EventLoop 被所有 Channel 共享。這讓很多 Channel 被最少數(shù)量的線程服務(wù)，而不是每個(gè) Channel 分配一個(gè)線程。

EventLoopGroup 負(fù)責(zé)分配一個(gè) EventLoop 到每個(gè)新創(chuàng)建的 Channel。在目前的實(shí)現(xiàn)中，采用循環(huán) (round-robin) 策略可以滿足一個(gè)平衡的分配，同一個(gè) Eventloop 還可能會(huì)被分配到多個(gè) Channel。

「本節(jié)參考」 第七章 EventLoop和線程模型

《Netty in Action》中文版

Essential Netty in Action 《Netty 實(shí)戰(zhàn)(精髓)》

Netty 4.1 JavaDoc