Netty核心概念(6)之Handler

1.前言

　本节介绍Netty中第三个重要的概念——Handler，这个在前两节都提到了，尤其是Channel和Handler联系紧密。handler本身的设计非常简单，但是所起到的作用却很大，Netty中对于handler的实现非常多（handler是控制socket io的各个生命周期的业务实现，netty实现了很多种协议，自然有很多handler类）。本节并不关心各种不同功能的handler具体实现，主要讲解handler的设计和作用及使用方法。

2.主要概念

2.1 ChannelHandler

　这个图可以看到ChannelHandler的基本结构，其有两个子类接口，ChannelInboundHandler和ChannelOutboundHandler。这也就是我之前常常提到的handler分成in和out类型，针对不同操作的方法。

　　handlerAdded()：handler被添加到channel的时候执行，这个动作就是由pipeline的添加handler方法完成的。对于服务端，在客户端连接进来的时候，就通过ServerBootstrapAcceptor的read方法，为每一个channel添加了handler。该方法对于handler而言是第一个触发的方法。

　　handlerRemoved()：handler被移除channel的时候执行，这个动作在pipeline中也存在，基本上是在channel断开的时候会进行这一步。

　　exceptionCaught()：捕获channel生命周期中异常处理的类，该方法被移动到ChannelInboundHandler中了。已经废弃。

　注解Sharable表明该handler可以被多个pipeline重复使用。

2.2 ChannelInboundHandler

　该接口主要负责的是业务逻辑，主要接口方法如下：

　　channelRegistered()：在channel注册到线程池的时候会被触发。

　　channelUnregistered()：在channel关闭的时候触发。

　　channelActive()：registered完成之后且channel处理active状态，首次注册状态。主要见AbstractChannel的register0(promise)方法。

　　channelnactive()：unregistered之前执行，主要见AbstractChannel的deregister方法。

　　channelRead()：这个主要见pipeline的fireChannelRead方法，其被channel在获取到数据的阶段进行调用，进而触发到handler的channelRead方法。

　　channelReadComplete()：这个和上面read方法一样，fireChannelReadComplete方法，被channel运行过程中read过程完成会进行调用。

　　userEventTriggered()：这个也是由pipeline提供的方法作为入口fireUserEventTriggered，这个就是触发一个事件了，以IdleStateHandler为例，其一般作为心跳检测事件，放入线程池执行，判断空闲就会触发该方法，传导到各个handler。

　　channelWritabilityChanged()：这个入口也在pipeline,但是好像没有怎么用到，channel并没有调用这个方法，一般也没怎么用该方法。

　　exceptionCaught()：这个入口同样在pipeline，被channel的读取过程抛出异常时触发，当然不只这一个地方。

　上述方法追根溯源都是通过pipeline来触发整个执行链的，后面讲到context时会详细说明一下这个过程。只需要知道入口在这个地方即可。

2.3 ChannelOutboundHandler

　比起in类型handler倾向于处理业务逻辑，out类型的handler更倾向于处理连接逻辑。下面是该类型的接口方法定义：

　　bind()：绑定端口的操作

　　connect()：连接远程地址

　　disconnect()：断开连接

　　close()：端口绑定的端口

　　deregister()：取消注册到线程池中

　　read()：设置监听读取事件

　　write()：写入数据的操作

　　flush()：刷新缓冲区，立刻发送。

　上述接口都是和连接相关的处理，而且这些都是通过pipeline的相关方法触发的，最终调用的是tail对象。实际上这个handler比较鸡肋，原因channel那节其实已经说明过，大部分实现类都做不了什么，最终都交给headContext对象调用unsafe相关方法由其处理了。大部分handler只对write方法进行了处理，其他都直接交给其他的handler处理了。我印象中之前Netty5好像要取消in和out的区别，outhandler太鸡肋了（Netty5已经放弃开发，官方的说法是forkjoin框架开发很复杂，还没准备好开发）。

2.4 ChannelHandlerContext

　handlerContext在之前我们就简要提到过，这个和pipeline联合使用，管理handler链。handler本身没有持有顺序关系，都是通过handlerContext完成的。handlerContext自身会通过配合handler造成顺着构成的链式顺序调用下去，这里会仔细说明一下这个过程。

　接口方法就不一一介绍了，看到的都是一些熟悉的方法，针对业务的起始调用fireXXX()，其它的方法就不进行介绍了。handlerContext和pipeline一样实现类很少，基本使用的就是DefaultChannelHandlerContext，其继承自AbstractChannelHandlerContext，大部分方法也都是在抽象父类中。下面具体介绍一下是如何工作的：

　还是回到pipeline的构造handler链的过程：

    protected DefaultChannelPipeline(Channel channel) {
        this.channel = ObjectUtil.checkNotNull(channel, "channel");
        succeededFuture = new SucceededChannelFuture(channel, null);
        voidPromise =  new VoidChannelPromise(channel, true);
 
        tail = new TailContext(this);
        head = new HeadContext(this);
 
        head.next = tail;
        tail.prev = head;
    }

　pipeline初始化的时候构建了tail和head两个handler，这两个是特殊的，位置不能替换的。

    public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
        final AbstractChannelHandlerContext newCtx;
        synchronized (this) {
            checkMultiplicity(handler);
 
            newCtx = newContext(group, filterName(name, handler), handler);
 
            addLast0(newCtx);
 
            // If the registered is false it means that the channel was not registered on an eventloop yet.
            // In this case we add the context to the pipeline and add a task that will call
            // ChannelHandler.handlerAdded(...) once the channel is registered.
            if (!registered) {
                newCtx.setAddPending();
                callHandlerCallbackLater(newCtx, true);
                return this;
            }
 
            EventExecutor executor = newCtx.executor();
            if (!executor.inEventLoop()) {
                newCtx.setAddPending();
                executor.execute(new Runnable() {
                    @Override
                    public void run() {
                        callHandlerAdded0(newCtx);
                    }
                });
                return this;
            }
        }
        callHandlerAdded0(newCtx);
        return this;
    }
 
　　private void addLast0(AbstractChannelHandlerContext newCtx) {
    　　AbstractChannelHandlerContext prev = tail.prev;
    　　newCtx.prev = prev;
    　　newCtx.next = tail;
    　　prev.next = newCtx;
    　　tail.prev = newCtx;
　　}

　先判断这个handler有没有被其他pipeline加载过，是否是sharable类型，进行相关设置。通过handler创建context。然后插入到tail前面，后面就是添加handler之后触发的方法，触发handlerAdd方法。通过addLast0方法，可以看见context中的参数prev和next被初始化了。也就是说通过当前的context能够找到前一个和后一个context了。下面抽出handler接口的其中一个方法，我们来研究一下handler链是怎么执行的。

    public ChannelHandlerContext fireChannelActive() {
        invokeChannelActive(findContextInbound());
        return this;
    }
 
    static void invokeChannelActive(final AbstractChannelHandlerContext next) {
        EventExecutor executor = next.executor();
        if (executor.inEventLoop()) {
            next.invokeChannelActive();
        } else {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    next.invokeChannelActive();
                }
            });
        }
    }
 
    private void invokeChannelActive() {
        if (invokeHandler()) {
            try {
                ((ChannelInboundHandler) handler()).channelActive(this);
            } catch (Throwable t) {
                notifyHandlerException(t);
            }
        } else {
            fireChannelActive();
        }
    }
 
　　private AbstractChannelHandlerContext findContextInbound() {
    　　AbstractChannelHandlerContext ctx = this;
    　　do {
        　　ctx = ctx.next;
    　　} while (!ctx.inbound);
    　　return ctx;
　　}

　handler的任何一个方法，在context中都是由三个这样的方法来构成链式执行的。static方法都是给pipeline调用的，其入参就是head，handler链的头结点。调用了invokeChannelActive()方法，这里就是我们的handler方法相关内容被触发了。乍一看好像执行完了就没了啊，这个地方要接下去就需要handler配合了。随便找一个handler，比如ChannelInboundHandlerAdapter，其相关方法都调用了ctx.fireChannelActive();  这里就接上了，ctx的fireChannelActive不就是回到了invokeChannelActive()方法了。其入参就不再是当前的context，而是通过findContextInbound来找到下一个in类型的handler，这也说明这个接口是针对in类型的接口。所以一个基本的循环就是ctx.invokeChannelActive(ctx) ->ctx.invokeChannelActive() -> hander.channelActive()->ctx.fireChannelActive(ctx)->findContextInbound()->ctx.invokeChannelActive(ctx)。这么个循环链，起点就是pipeline的invokeChannelActive(head)，终点就是handler.channelActive()没有调用ctx.channel的时候，最后的tailContext就是没有执行任何操作，所以执行到这链路就断了。

3.后记

　本节对handler的一个基本内容进行了说明，主要讲解了handlerContext的执行过程，明确了调用链的入口在于pipeline，通过pipeline和context的控制，保证链的执行。channel的生命周期控制pipeline就能控制整个handler的执行。下图给个具体说明：

　　上图综合了前几章的内容，整个核心调用过程就是这些了，但是还没有设置线程问题，所以启动类以及线程相关没有加入到图中，下一章将对Netty的线程模型进行分析。