Pipeline outbound

netty源码死磕8

Pipeline outbound 出站流程揭秘

1. Pipeline outbound流程

1.1. 出站的定义

简单回顾一下。

出站（outbound） 操作，通常是处于上层的Netty channel，去操作底层Java  NIO channel/OIO Channel。

主要出站（outbound）操作如下：

1. 端口绑定 bind

2. 连接服务端 connect

3. write写通道

4.  flush刷新通道

5.  read读通道

6. 主动断开连接 disconnect

7. 主动关闭通道 close

最为常见，也是最容易理解的出站操作，是第3个操作 —— write写通道。

一个Netty Channel的write 出站操作 实例：

// server向 Channel写登录响应
ctx.channel().write(“恭喜，登录成功”);

//....

1.2. 出站处理器Handler

对于出站操作，有相应的出站Handler处理器。

有四个比较重要的出站Handler类。

这个四个 Handler 相关的类结构图如下：

在抽象的ChannelOutboundHandler 接口中，定义了所有的出站操作的方法声明。

在ChannelOutboundHandlerAdapter 出站适配器中，提供了出站操作的默认实现。如果要实现定制的出站业务逻辑，继承ChannelOutboundHandlerAdapter 适配器即可。ChannelOutboundHandlerAdapter 面向的是通用的出站处理场景。

有一个特殊场景的出站处理器——HeadContext。先按下不表，稍候重点介绍。

1.3. 出站的上下文包裹器Context

虽然有专门的Handler，但是，并没有专门的出站Context上下文包裹器。

强调一下：

没有单独的出站上下文Context基类。出站和入站，复用了同一个上下文Context基类。它就是AbstractChannelHandlerContext。

在这个AbstractChannelHandlerContext基类中，定义了每一个出站操作的默认实现。

基本的出站方法如下:

AbstractChannelHandlerContext.bind(SocketAddress, ChannelPromise)

AbstractChannelHandlerContext.connect(SocketAddress,SocketAddress, hannelPromise)

AbstractChannelHandlerContext.write(Object, ChannelPromise)

AbstractChannelHandlerContext.flush()

AbstractChannelHandlerContext.read()

AbstractChannelHandlerContext.disconnect(ChannelPromise)

AbstractChannelHandlerContext.close(ChannelPromise)

赘述一遍：

Context类型的接口是ChannelHandlerContext，抽象的基类是AbstractChannelHandlerContext。

出站和入站的区分，通过基类AbstractChannelHandlerContext的两个属性来完成——outbound、intbound。

出站Context的两个属性的值是：

（1）AbstractChannelHandlerContext基类对象的属性outbound的值为false

（2）AbstractChannelHandlerContext基类对象的属性intbound值为true

Pipeline 的第一个节点HeadContext，outbound属性值为true，所以一个典型的出站上下文。

1.4. 流逼哄哄的HeadContext

为什么说流逼哄哄呢？

因为：HeadContext不光是一个出站类型的上下文Context， 而且它完成整个出站流程的最后一棒。

不信，看源码：

final class HeadContext extends AbstractChannelHandlerContext
        implements ChannelOutboundHandler, ChannelInboundHandler

{
 private final Unsafe unsafe;
 HeadContext(DefaultChannelPipeline pipeline)

{
  //父类构造器
  super(pipeline, null, HEAD_NAME, false, true);
  //...

}

}

在HeadContext的构造器中，调用super 方法去初始化基类AbstractChannelHandlerContext实例。

注意，第四个、第五个参数非常重要。

第四个参数false，此参数对应是是基类inbound的值，表示Head不是入站Context。

第五个参数true，此参数对应是是基类outbound的值，表示Head是一个出站Context。

所以，在作为上下文Context角色的时候，HeadContext是黑白分明的、没有含糊的。它就是一个出站上下文。

但是，顺便提及一下，HeadContext还承担了另外的两个角色：

（1）入站处理器

（2）出站处理器

所以，总计一下，其实HeadContext 承担了3个角色。

HeadContext作为Handler处理器的角色使用的时候，HeadContext整个Handler是一个两面派，承担了两个Handler角色：

（1）HeadContext是一个入站Handler。HeadContext 是入站流水线处理处理的起点。是入站Handler队列的排头兵。

（2）HeadContext是一个出站Handler。HeadContext 是出站流水线处理的终点，完成了出站的最后棒—— 执行最终的Java IO Channel底层的出站方法。

整个出站处理的流水线，是如何一步一步，流转到最后一棒的呢？

1.5. TailContext出站流程的起点

出站处理，起点在TailContext。

这一点，和入站处理的流程刚好反过来。

在Netty 的Pipeline流水线上，出站流程的起点是TailContext，终点是HeadContext，流水线执行的方向是从尾到头。

强调再强调：

出站流程，只有outbound 类型的 Context 参与。inbound 类型的上下文Context不参与（TailContext另说）。

上图中，橙色的是outbound Context ，是出站类型，肯定参与出站流程的。紫色的是inbound context，是入站类型的上下文Context。

上图中，橙色的Context有两个，分别是EncoderContext和HeaderContext两个Context。EncoderContext 负责出站报文的编码，一般将Java 对象编码成特定格式的传输数据包data  package。HeaderContext 负责将数据包写出到Channel 通道。

在Pipeline创建的时候，加入Handler之前，Pipeline就是有两个默认的Context——HeadContext，和TailContext。

最初的Pipeline结构，如下图所示：

TailContext是出站起点，HeadContext是出站的终点。也就是说，Pipeline 从创建开始，就具已经备了Channel出站操作的能力的。

关键的问题是：作为出站的起点，为什么TailContext不是橙色呢？

首先，TailContext不是outbound类型，反而，是inbound入站类型的上下文包裹器。

其次，TailContext 在出站流水线上，仅仅是承担了一个启动工作，寻找出第一个真正的出站Context，并且，将出站的第一棒交给他。

总之，在出站流程上，TailContext作用，只是一把钥匙，仅此而已。

1.6. 出站write操作的流程实例

老规则，先上例子。

以最为常见、最好理解的出站操作——Netty  Channel 出站write操作为例，将outbound处理出站流程做一个详细的描述。

整个写出站的入站处理流程图，如下：

1.7. 出站操作的最初源头

再看一次Netty Channel的write出站实例：

// server向客户 Channel写登录响应
ctx.channel().write(“恭喜，登录成功”);

//....

写操作一般的源头是从Netty 的通道channel开始的。当服务器需要发送一个业务消息到客户端，会使用到之前打开的客户端通道channel，调用通道channel的出站写操作write方法，完成写操作。

这个write方法的Netty 源码，在基类AbstractChannel 实现了一个基础的版本。

代码如下：

public abstract class AbstractChannel extends DefaultAttributeMap implements Channel

{

 //…

@Override
public ChannelFuture write(Object msg) {
    return pipeline.write(msg);
}

//…

}

回忆一下通道和流水线的关系：一个通道一个pipeline流水线。一个流水线串起来一系列的Handler。

所以，通道将出站的操作，直接委托给了自己的成员——pipeline流水线。直接调用pipeline流水线的出站操作去完成。

也就是说，Channel 是甩手掌柜，将出站操作委托给了Pipeline。然而，Pipeline还是一个甩手掌柜。

Pipeline直接甩给了谁呢？

Pipeline 将出站操作，甩给双向链表的最后一个节点—— tail 节点。Pipeline的源码如下：

public class ChannelPipeline …..

{

//…

@Override

public final ChannelFuture write(Object msg) {

  return tail.write(msg);

}

//…

}

于是乎，在pipeline的链表上，tail节点，偏偏就是出站操作的启动节点。

1.8. Tail是出站操作的起点

TailContext 类的定义中，并没有实现 write写出站的方法。这个write(Object msg) 方法，定义在TailContext的基类——AbstractChannelHandlerContext 中。

代码如下：

abstract class AbstractChannelHandlerContext

extends DefaultAttributeMap implements ChannelHandlerContext

{

//……

@Override

public ChannelFuture write(Object msg) {

//….

return write(msg, newPromise());

}

@Override

public ChannelFuture write(final Object msg, final ChannelPromise promise) {

//…

write(msg, false, promise);

return promise;

}

//……

@Override

public ChannelPromise newPromise() {

return new DefaultChannelPromise(channel(), executor());

}

//第三个重载的write

 private void write(Object msg, boolean flush, ChannelPromise promise)  {

       //...

   //找出下一棒 next

     AbstractChannelHandlerContext next = findContextOutbound();

       //....

    //执行下一棒 next.invoke

       next.invokeWrite(msg, promise);

       //...

 }

}

有三个版本的write重载方法：

ChannelFuture write(Object msg)

ChannelFuture write(Object msg，ChannelPromise promise)

ChannelFuture write(Object msg， boolean flush，ChannelPromise promise)

调用的次序是：

第一个调用第二个，第二个调用第三个。

第一个write 创建了一个ChannelPromise 对象，这个对象实例非常重要。因为Netty的write出站操作，并不一定是一调用write就立即执行，更多的时候是异步执行的。write返回的这个ChannelPromise 对象，是专门提供给业务程序，用来干预异步操作的过程。

可以通过ChannelPromise 实例，监听异步处理的是否结束，完成write出站正真执行后的一些业务处理，比如，统计出站操作执行的时间等等。

ChannelPromise 接口，继承了 Netty 的Future的接口，使用了Future/Promise 模式。这个是一种异步处理干预的经典的模式。疯狂创客圈另外开了一篇文章，专门讲述Future/Promise 模式。

第二个write，最为单薄。简单的直接调用第三个write，调用前设置flush 参数的值为false。flush 参数，表示是否要将缓冲区ByteBuf中的数据，立即写入Java IO Channel底层套接字，发送出去。一般情况下，第二个write设置了false，表示不立即发出，尽量减少底层的发送，提升性能。

第三个write，最为重要，也最为复杂。分成两步，第一步是找出下一棒 next，下一棒next也是一个出站Context。第二步是，执行下一棒的invoke方法，也即是next.invokeWrite(msg, promise);

完成以上的三步操作，TailContext 终于将write出站的实际工作，交到了第一棒outbound Context的手中。

至此，TailContext终于完成的启动write流程的使命。

1.9. 出站流程小迭代的五个动作

一般来说，Pipeline上会有多个OutBound Context（包裹着Handler），每一个OutBound Context 的处理，可以看成是大的流水处理中的一次小迭代。

每一个小迭代，有五个动作。

五个动作，具体如下：

（1）context.write(msg，promise)

（2）context.write(msg，flush，promise)

（3）context.findContextOutbound();

（4）next.invokeWrite(msg,promise)

（5）handler.write(this,msg,promise)

Context中的write(msg,promise)方法，是整个小迭代的起点。局部的流程图如下：

整个五个动作中，只有第五步在Handler中定义。其他的四步，都在Context中定义。

第一步、第二步的 write 方法在前面已经详细介绍过了。这两步主要完成promise实例的 创建，flush 参数的设置。

现在到了比较关键的步骤：第三步。这一步是寻找出站的下一棒。

1.10. findContextOutbound找出下一棒

出站流程的寻找下一棒的工作，和入站处理的寻找下一棒的方向，刚好反过来。

出站流程，查找的方向是从尾到头。这就用到的双向链表的指针是prev——向前的指针。具体来说，从当前的context开始，不断的使用prev指针，进行循环迭代查找。一直找到终点HeadContext，结束。

Netty源码如下：

abstract class AbstractChannelHandlerContext extends DefaultAttributeMap implements ChannelHandlerContext

{

//…
private AbstractChannelHandlerContext findContextOutbound() {
    AbstractChannelHandlerContext ctx = this;
    do {
        ctx = ctx.prev;
    } while (!ctx.outbound);
    return ctx;
}

//…

}

这个是一个标准的链表的前向查询。

每一次的查找，this表示当前的查询所在的context 节点，this.prev表示前一个context节点。

查找时，用到的双向链表的指针是prev——向前的指针。通过while循环，一直往Pipeline的前面查找，如果前面的context不是outbound出站上下文，则一直向前。直到，直到，一直到查找出下一个出站Context上下文为止。

最初的查找，从TailContext开始，this就是TailContext。后续的每一次查找，都是从当前的Context上下文开始的。

1.11. context的invokeWrite

找到下一棒出站Context后，执行context的invokeWrite的操作。

源码如下：

abstract class AbstractChannelHandlerContext

extends DefaultAttributeMap implements ChannelHandlerContext

{

//……

    private void invokeWrite(Object msg, ChannelPromise promise) {

        //...

            invokeWrite0(msg, promise);

       //...

    }

//……

    private void invokeWrite0(Object msg, ChannelPromise promise) {

        try {

            ((ChannelOutboundHandler) handler()).write(this, msg, promise);

        } catch (Throwable t) {

            notifyOutboundHandlerException(t, promise);

        }

    }

}

context的invokeWrite操作，最终调用到了其所包裹的handler的write方法。完成 定义在handler中的业务处理动作。

1.12. 默认的write出站实现

默认的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);
  }
//……
}

Handler的write出站操作，已经到了一轮出站小迭代的最后一步。这个默认的write方法，简单的调用context. write方法，回到了小迭代的第一步。

换句话说，默认的ChannelOutboundHandlerAdapter 中的handler方法，是流水线的迭代一个一个环节前后连接起来，的关键的一小步，保证了流水线不被中断掉。

反复进行小迭代，迭代处理完中间的业务handler之后，就会走到流水线的HeadContext。

1.13. HeadContext出站的最后一棒

在出站迭代处理pipeline的最后一步， 会来到HeadContext。

HeadContext是如何完成最后一棒的呢？

上源码：

final class HeadContext extends AbstractChannelHandlerContext
        implements ChannelOutboundHandler, ChannelInboundHandler
{
    private final Unsafe unsafe;
    HeadContext(DefaultChannelPipeline pipeline) {
         //父类构造器
        super(pipeline, null, HEAD_NAME, false, true);
        this.unsafe = pipeline.channel().unsafe();
       //...
}

public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
       this.unsafe.write(msg, promise);
}
}

HeadContext 包含了一个unsafe 成员。 这个unsafe 成员，是一个只供在netty内部使用的类型。

unsafe 主要功能，就是完成对 Java NIO 底层Channel的写入 。

由此可见，在Netty中的三大上下文包裹器HeadContext、TailContext 、 DefaultChannelHandlerContext中，HeadContext是离 Java NIO 底层Channel最近的地方。三大包裹器，除了HeadContext，也没有谁包含Unsafe。对完成出站的最终操作职能来说，没有谁比HeadContext 更加直接。所以，这个出站处理的最后一棒，只能是HeadContext 了，呵呵。

至此为止，write出站的整个流水线流程，已经全部讲完。

从具体到抽象，我们再回到出站处理的通用流程。

1.14. 出站操作的全流程

基本上，在流程上，所有的出站事件的处理过程，是一致的。

为了方便说明，使用OUT_EVT符号代替一个通用出站操作。

通用的出站Outbound操作处理过程，大致如下:

（1）channel.OUT_EVT(msg);

（2）pipeline.OUT_EVT(msg);

（3）context.OUT_EVT(msg);

（4）context.OUT_EVT(msg,promise);

（5）context.OUT_EVT(msg,flush,promise);

（6）context.findContextOutbound();

（7）next.invoke(msg,flush,promise);

（8）handle.OUT_EVT(context,msg,promise);

（9）context.OUT_EVT(msg,promise);

上面的流程，如果短时间内看不懂，可以在回头看看write出站的实例。

---

无编程不创客，无案例不学习。疯狂创客圈，一大波高手正在交流、学习中!

疯狂创客圈 Netty 死磕系列 10多篇深度文章： 【博客园 总入口】  QQ群：104131248