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

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

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

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

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

ChannelHandler 有兩個重要的子接口：

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

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

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

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

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

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

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

ChannelPromise 是 ChannelFuture 的子接口

而 ChannelFuture 是不可變對象

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

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

    ReferenceCountUtil.release(「ByteBuf 的對象」)

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

2. 輸出方向「Outbound」
在輸出方向，如果處理一個 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)被處理
}

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

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

一個 ChannelPipeline 可看成是一串 ChannelHandler 實例，攔截穿過 Channel 的輸入輸出 event。

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

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

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

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

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

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

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

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

EventLoop 始終由一個線程驅(qū)動

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

一個 Channel 只擁有一個 EventLoop

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

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

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

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

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

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

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

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

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

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

《Netty in Action》中文版

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

Netty 4.1 JavaDoc