6.3 Interface ChannelHandlerContext

一個ChannelHandlerContext代表了一個ChannelHandler和ChannelPipeline之間的關係，ChannelHandlerContext創建於ChannelHandler被載入到ChannelPipeline的時候，ChannelHandlerContext主要功能是管理在同一ChannelPipeline中各個ChannelHandler的互動

ChannelHandlerContext有很多方法，其中的一些方法也出現在Channel和ChannelPipeline中，但是相同的方法卻有一些不同的效果，如果你在Channel或者在ChannelPipeline例項中實現這些方法，它們會傳播到整個管道，同樣的方法如果被ChannelHandlerContext執行的時候，那麼它會在當前關聯的ChannelHandler中開始執行，然後只會傳播到管道中符合條件（符合方向的有興趣的）的下一個ChannelHandler處理

表6.10總結了ChannelHandlerContext的APIs

當你使用ChannelHandlerContext的時候，請牢記以下幾點原則：

1）與ChannelHandlerContext關聯的ChannelHandler是不會改變的，所以如果對其引用做一份快取是安全的

2）ChannelHandlerContext的方法與定義在其他class中的方法是不一樣的，它有著較短的生命週期，這個可以被用來儘可能的提高應用的效能

6.3.1 Using ChannelHandlerContext

在這個小節中，我們將討論如何使用ChannelHandlerContext，並且檢視由ChannelHandlerContext，Channel，ChannelPipeline提供的一些方法，圖6.4向你展示了它們三者之間的關係

在下面的程式碼清單中，你將從ChannelHandlerContext中獲取一個Channel的引用，通過呼叫Channel的write的方法寫在管道里會引起一個寫入流

下面的程式碼清單也展示了一個相似的例子，這次也是用ChannelPipeline寫入，我們可以從ChannelHandlerContext中獲取的ChannelPipeline引用

程式碼清單6.6和程式碼清單6.7是很相似的，都如圖6.5所示，你必須注意到通過Channel或者ChannelPipeline呼叫write方法都會使事件沿著管道傳播，這一點是很重要的，從一個Channel到下一個Channel的移動是由ChannelHandlerContext管控的

為什麼有時候我們需要在ChannelPipeline中的某些具體的地方開始傳播一個事件呢？

1）減少事件在那些對該事件不感興趣的處理器傳播的損耗

2）防止那些“感興趣”的處理器處理後產生不好的影響

為了從一個指定的ChannelHandler開始執行處理，你必須指定一個ChannelHandler處理器之前的那個ChannelHandlerContext，這個ChannelHandlerContext會呼叫與它關聯的那個ChannelHandler，這個ChannelHandler也就是我們指定的那個處理器

下面的程式碼清單和圖6.6說明了這個使用的方法

如圖6.6所示，資訊從圖中第二個ChannelHandler中開始在ChannelPipeline中傳播，跳過了前一個

我們剛才描述使用的是一個很常見的一種使用方式，呼叫一個特定的ChannelHandler例項是一個非常有用的操作方式

6.3.2 Advanced uses of ChannelHandler and ChannelHandlerContext

在我們之前看見的6.6清單所示，我們通過ChannelHandlerContext的pipeline方法獲取到一個ChannelPipeline的引用，這裡可以在執行的時候操作管道中的ChannelHandler，這裡可以在複雜的業務場景中用到，例如，你可以通過增加一個ChannelHandler到管道中來支援動態協議的改變

另一個使用的好處就是獲取一個ChannelHandlerContext的一個引用，這個引用的快取可以支援“延遲使用”，這樣可以發生在ChannelHandler之外甚至可以給不同的執行緒都執行，下面的程式碼清單展示了這種模式

因為一個ChannelHandler可以屬於多個ChannelPipeline，它也可以繫結多個ChannelHandlerContext例項，如果一個ChannelHandler想要有這樣的功能，就必須以@Sharable註解註釋這個ChannelHandler，否則，嘗試將其加入到不止一個ChannelPipeline中去的時候，會報出異常，很明顯，使用這樣的支援多執行緒的channel你必須保證該類是執行緒安全的，無狀態的

下面的程式碼清單展示了這個模式一個正確的實現

先前的ChannelHandler實現了滿足其被在多個管道使用時的多個需求，顧名思義，它被@Sharable註解了自己，並且它不包含任何的狀態，相反，下面的6.11程式碼清單就可能引起一些問題：

這個程式碼的問題是因為它是有狀態的，因為有一個count的變數，這個變數會計算該方法的呼叫，增加這個類的例項到ChannelPipeline中去就可能會出現錯誤，當它被併發的channel觸發的時候出現

總而言之，你必須保證你的ChannelHandler是執行緒安全的在你使用@Sharable的時候

WHY SHARE A CHANNELHANDLER? 在多個ChannelPipeline中使用同一個ChannelHandler的一個正常理由是多個Channel的統計資訊

我們對ChannelHandlerContext的討論做了總結，並且講解了它與其他元件之間的關係，下一個小節，我們討論一下異常處理

6.4 Exception handling

異常處理對於任意一個重大的系統都是一個很重要的模組，它可以以多種方式去完成這個模組，相應的，Netty提供了一些輸入輸出處理時產生異常的一些處理選項，這個小節將幫助你理解這些方式，並找出最合適滿足你需要的處理方式

6.4.1 Handling inbound exceptions

在輸入事件處理過程中一個異常丟擲時，這個異常將會在觸發該異常的ChannelInboundHandler的地方開始在ChannelPipeline傳播，為了處理這樣的異常，你需要在你的ChannelPipeline實現中重寫如下的方法

下面的程式碼清單向你展示一個簡單的異常處理例子：關閉channel然後打印出異常資訊

因為發生的異常可以繼續沿著輸入的方向傳播，這就保證了無論異常在哪裡發生，所有在ChannelPipeline中的業務邏輯都會處理，且所有的異常都會被捕獲處理

關於如何處理異常更多的情況下是取決你具體的應用程式，你可能會關閉channel連線，也可能去嘗試去恢復，當然，如果你沒有實現任何異常處理的方法，Netty將會記錄異常沒有被處理

總結如下：

1）預設的ChannelHandler的exceptionCaught的實現會把異常傳給管道中的下一個處理器

2）如果一個異常到達了一個管道的結尾，它將被記錄為未被處理

3）來定義自定義的處理，你重寫了exceptionCaught方法，這將是你自己的決定你是否決定將其接著傳播到下游處理器

6.4.2 Handling outbound exceptions

處理輸出操作的正常實現或者異常問題是基於以下幾點列出的機制：

1）每一個輸出操作返回一個ChannelFuture，註冊到ChannelFuture上的ChannelFutureListener會被通知操作是否成功或者失敗當操作完成的時候

2）幾乎所有的ChannelOutboundHandler都會傳遞一個ChannelPromise例項，作為ChannelFuture的子類，它也可以被監聽器管控來獲取非同步通知，但是ChannelPromise為實時通知提供可寫的方法

在ChannelFuture例項中增加一個ChannelFutureListener是為了呼叫addListener方法，有兩種方法可以完成這個實現，一個最最常用的方式是呼叫由輸出操作返回的ChannelFuture的addListener方法

下面的程式碼清單使用了這個方法來增加一個ChannelFutureListener，用來列印一次然後關閉Channel

第二個方式是通過在ChannelOutboundHandler方法中作為引數的傳遞的ChannelPromise增加一個ChannelFutureListener，下面的程式碼清單展示了與上面程式碼有相同功能的實現

TIPS:ChannelPromise的寫方法

通過呼叫ChannelPromise的setSuccess或者setFailure方法，你可以是呼叫者在ChannelHandler返回的時候，立馬知道操作的是否成功

怎麼才知道兩個方式哪個更好呢？如果你想要更仔細地處理異常，那麼你會發現使用程式碼清單6.13中更加合適，但是如果你想更加專業的處理異常，你會發現6.14顯得更加簡單

如果ChannelOutboundHandler自己本身發生了異常，那麼會發生什麼呢？這種情況下，Netty本身會通知註冊到相對應的ChannelPromise上的任意監聽器

6.5 Summary

在這個章節，我們討論了Netty的資料處理元件ChannelHandler，我們討論了多個ChannelHandler鏈在一起，討論了ChannelInboundHandler和ChannelOutboundHandler如何與ChannelPipeline互動的

下一個章節我們討論Netty的編碼抽象，這個將比直接使用底層的ChannelHandler實現來編寫編碼和解碼更加簡單