ChannelPipeline

ChannelPipeline不是單獨存在,它肯定會和Channel、ChannelHandler、ChannelHandlerContext關聯在一起,所以有關概念這裡一起講。

一、ChannelHandler

1、概念

先看圖

ChannelHandler下主要是兩個子介面

ChannelInboundHandler(入站):處理輸入資料和Channel狀態型別改變。

介面卡: ChannelInboundHandlerAdapter（介面卡設計模式）

常用的: SimpleChannelInboundHandler

ChannelOutboundHandler(出站): 處理輸出資料

介面卡: ChannelOutboundHandlerAdapter

每一個Handler都一定會處理出站或者入站(可能兩者都處理資料),例如對於入站的Handler可能會繼承SimpleChannelInboundHandler或者ChannelInboundHandlerAdapter,

而SimpleChannelInboundHandler又是繼承於ChannelInboundHandlerAdapter，最大的區別在於SimpleChannelInboundHandler會對沒有外界引用的資源進行一定的清理,

並且入站的訊息可以通過泛型來規定。

這裡為什麼有設配器模式呢？

我們在寫自定義Handel時候,很少會直接實現上面兩個介面,因為介面中有很多預設方法需要實現,所以這裡就採用了設配器模式,ChannelInboundHandlerAdapter和

ChannelInboundHandlerAdapter就是設配器模式的產物,讓它去實現上面介面,實現它所有方法。那麼你自己寫自定義Handel時,只要繼承它,就無須重寫上面介面的所有方法了。

2、Channel 生命週期(執行順序也是從上倒下)

（1）channelRegistered: channel註冊到一個EventLoop。

（2）channelActive: 變為活躍狀態（連線到了遠端主機），可以接受和傳送資料

（3）channelInactive: channel處於非活躍狀態，沒有連線到遠端主機

（4）channelUnregistered: channel已經建立，但是未註冊到一個EventLoop裡面，也就是沒有和Selector繫結

3、ChannelHandler 生命週期

handlerAdded： 當 ChannelHandler 新增到 ChannelPipeline 呼叫

handlerRemoved： 當 ChannelHandler 從 ChannelPipeline 移除時呼叫

exceptionCaught： 當 ChannelPipeline 執行丟擲異常時呼叫

二、ChannelPipeline

1、概念

先看圖

ChannelPipeline類是ChannelHandler例項物件的連結串列，用於處理或截獲通道的接收和傳送資料。它提供了一種高階的擷取過濾模式（類似serverlet中的filter功能），讓用

戶可以在ChannelPipeline中完全控制一個事件以及如何處理ChannelHandler與ChannelPipeline的互動。

對於每個新的通道Channel，都會建立一個新的ChannelPipeline，並將器pipeline附加到channel中。

下圖描述ChannelHandler與pipeline中的關係，一個io操作可以由一個ChannelInboundHandler或ChannelOutboundHandle進行處理，並通過呼叫ChannelInboundHandler

處理入站io或通過ChannelOutboundHandler處理出站IO。

2、常用方法

      addFirst(...)   //新增ChannelHandler在ChannelPipeline的第一個位置
     addBefore(...)   //在ChannelPipeline中指定的ChannelHandler名稱之前新增ChannelHandler
      addAfter(...)   //在ChannelPipeline中指定的ChannelHandler名稱之後新增ChannelHandler
       addLast(...)   //在ChannelPipeline的末尾新增ChannelHandler
        remove(...)   //刪除ChannelPipeline中指定的ChannelHandler
       replace(...)   //替換ChannelPipeline中指定的ChannelHandler

ChannelPipeline可以動態新增、刪除、替換其中的ChannelHandler，這樣的機制可以提高靈活性。示例:

1.    ChannelPipeline pipeline = ch.pipeline(); 
2.    FirstHandler firstHandler = new FirstHandler(); 
3.    pipeline.addLast("handler1", firstHandler); 
4.    pipeline.addFirst("handler2", new SecondHandler()); 
5.    pipeline.addLast("handler3", new ThirdHandler()); 
6.    pipeline.remove("“handler3“"); 
7.    pipeline.remove(firstHandler); 
8.    pipeline.replace("handler2", "handler4", new FourthHandler());<span style="font-family:Microsoft YaHei;font-size:14px;">

3、入站出站Handler執行順序

一般的專案中，inboundHandler和outboundHandler有多個，在Pipeline中的執行順序？

重點記住:InboundHandler順序執行，OutboundHandler逆序執行。

問題: 下面的handel的執行順序？

          ch.pipeline().addLast(new InboundHandler1());
          ch.pipeline().addLast(new OutboundHandler1());
          ch.pipeline().addLast(new OutboundHandler2());
          ch.pipeline().addLast(new InboundHandler2());
  或者：
          ch.pipeline().addLast(new OutboundHandler1());
          ch.pipeline().addLast(new OutboundHandler2());
          ch.pipeline().addLast(new InboundHandler1());
          ch.pipeline().addLast(new InboundHandler2());

其實上面的執行順序都是一樣的:

 InboundHandler1--> InboundHandler2 -->OutboundHandler2 -->OutboundHandler1

結論

1）InboundHandler順序執行，OutboundHandler逆序執行

2）InboundHandler之間傳遞資料，通過ctx.fireChannelRead(msg)

3）InboundHandler通過ctx.write(msg)，則會傳遞到outboundHandler

4) 使用ctx.write(msg)傳遞訊息，Inbound需要放在結尾，在Outbound之後，不然outboundhandler會不執行；

但是使用channel.write(msg)、pipline.write(msg)情況會不一致，都會執行,那是因為channel和pipline會貫穿整個流。

5) outBound和Inbound誰先執行，針對客戶端和服務端而言，客戶端是發起請求再接受資料，先outbound再inbound，服務端則相反。

三、ChannelHandlerContext

ChannelPipeline並不是直接管理ChannelHandler，而是通過ChannelHandlerContext來間接管理，這一點通過ChannelPipeline的預設實現DefaultChannelPipeline可以看出來。

DefaultChannelHandlerContext和DefaultChannelPipeline是ChannelHandlerContext和ChannelPipeline的預設實現在DefaultPipeline內部

DefaultChannelHandlerContext組成了一個雙向連結串列。我們看下DefaultChannelPipeline的建構函式:

/**
  * 可以看到,DefaultChinnelPipeline 內部使用了兩個特殊的Hander 來表示Handel鏈的頭和尾。
  */
 public DefaultChannelPipeline(AbstractChannel channel) {
        if (channel == null) {
            throw new NullPointerException("channel");
        }
        this.channel = channel;
 
        TailHandler tailHandler = new TailHandler();
        tail = new DefaultChannelHandlerContext(this, null, generateName(tailHandler), tailHandler);
 
        HeadHandler headHandler = new HeadHandler(channel.unsafe());
        head = new DefaultChannelHandlerContext(this, null, generateName(headHandler), headHandler);
 
        head.next = tail;
        tail.prev = head;
    }

所以對於DefaultChinnelPipeline它的Handel頭部和尾部的Handel是固定的,我們所新增的Handel是新增在這個頭和尾之前的Handel。（下面這個圖更加清晰）

四、幾者關係

先大致說下什麼是Channel

通常來說, 所有的 NIO 的 I/O 操作都是從 Channel 開始的. 一個 channel 類似於一個 stream。在Netty中,Channel是客戶端和服務端建立的一個連線通道。

雖然java Stream 和 NIO Channel都是負責I/O操作,但他們還是有許多區別的:

1）我們可以在同一個 Channel 中執行讀和寫操作, 然而同一個 Stream 僅僅支援讀或寫。

2）Channel 可以非同步地讀寫, 而 Stream 是阻塞的同步讀寫。

3）Channel 總是從 Buffer 中讀取資料, 或將資料寫入到 Buffer 中。

幾者的關係圖如下:

總結:

一個Channel包含一個ChannelPipeline，建立Channel時會自動建立一個ChannelPipeline，每個Channel都有一個管理它的pipeline，這關聯是永久性的。

這點從原始碼中就可以看出,我之前寫的部落格裡有說到:【Netty】5 原始碼 Bootstrap。每一個ChannelPipeline中可以包含多個ChannelHandler。所有ChannelHandler

都會順序加入到ChannelPipeline中,ChannelHandler例項與ChannelPipeline之間的橋樑是ChannelHandlerContext例項。

五、整個傳播流程

現在將上面的整個傳播流程,通過原始碼大致走一遍。

為了搞清楚事件如何在Pipeline裡傳播，讓我們從Channel的抽象子類AbstractChannel開始，下面是AbstractChannel#write()方法的實現：

public abstract class AbstractChannel extends DefaultAttributeMap implements Channel {
    // ...
    @Override
    public Channel write(Object msg) {
        return pipeline.write(msg);
    }
    // ...
}

AbstractChannel直接呼叫了Pipeline的write()方法：

再看DefaultChannelPipeline的write()方法實現：

final class DefaultChannelPipeline implements ChannelPipeline {
    // ...
    @Override
    public ChannelFuture write(Object msg) {
        return tail.write(msg);
    }
    // ...
}

因為write是個outbound事件，所以DefaultChannelPipeline直接找到tail部分的context，呼叫其write()方法：

接著看DefaultChannelHandlerContext的write()方法

final class DefaultChannelHandlerContext extends DefaultAttributeMap implements ChannelHandlerContext {
    // ...
    @Override
    public ChannelFuture write(Object msg) {
        return write(msg, newPromise());
    }
 
    @Override
    public ChannelFuture write(final Object msg, final ChannelPromise promise) {
        if (msg == null) {
            throw new NullPointerException("msg");
        }
 
        validatePromise(promise, true);
 
        write(msg, false, promise);
 
        return promise;
    }
 
 private void write(Object msg, boolean flush, ChannelPromise promise) {
 DefaultChannelHandlerContext next = findContextOutbound();
 next.invokeWrite(msg, promise);
 if (flush) {
 next.invokeFlush();
 }
 }
 
 private DefaultChannelHandlerContext findContextOutbound() {
 DefaultChannelHandlerContext ctx = this;
 do {
 ctx = ctx.prev;
 } while (!ctx.outbound);
 return ctx;
 }
 
 private void invokeWrite(Object msg, ChannelPromise promise) {
 try {
 ((ChannelOutboundHandler) handler).write(this, msg, promise);
 } catch (Throwable t) {
 notifyOutboundHandlerException(t, promise);
 }
 }
 
   // ...
}

context的write()方法沿著context鏈往前找，直至找到一個outbound型別的context為止，然後呼叫其invokeWrite()方法

invokeWrite()接著呼叫handler的write()方法

最後看看ChannelOutboundHandlerAdapter的write()方法實現：

public class ChannelOutboundHandlerAdapter extends ChannelHandlerAdapter implements ChannelOutboundHandler {
    // ...
    @Override
    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
        ctx.write(msg, promise);
    }
    // ...
}

預設的實現呼叫了context的write()方法而不做任何處理，這樣write事件就沿著outbound鏈繼續傳播：

可見，Pipeline的事件傳播，是靠Pipeline，Context和Handler共同協作完成的。