Netty源码分析之ChannelHandler

一、ChannelHandler

public interface ChannelHandler {
    void handlerAdded(ChannelHandlerContext var1) throws Exception;

    void handlerRemoved(ChannelHandlerContext var1) throws Exception;

    /** @deprecated */
    @Deprecated
    void exceptionCaught(ChannelHandlerContext var1, Throwable var2) 
    throws Exception;

    @Inherited
    @Documented
    @Target({ElementType.TYPE})
    @Retention(RetentionPolicy.RUNTIME)
    public @interface Sharable {
    }
}

从源码看ChannelHandler就三个方法，handler的添加、移除事件和异常捕获，以及一个内部注解。从使用上来看，我们用netty编写应用时候，都会写一个ChannelHandler的实现类，去处理业务请求，或者直接使用netty自带的ChannelHandler的实现。

前文对ChannelPipeline的分析可知，ChannelPipeline是维护ChannelHandlerContext双向链表的数据结构，链表中的每个context节点都是对ChannelHandler的封装。所以也可以说是维护了ChannelHandler的双向链表。

ChannelHandler有两个子接口：ChannelInboundHandler和ChannelOutboundHandler，这两个接口也是netty的核心接口之一。

二、入站（Inbound）和出站（Outbound）

**入站：**实现了ChannelInboundHandler处理的消息称为入站，以服务端为主，来说当消息从客户端传递到服务端的时候，服务端会调用ChannelInboundHandler实现类去处理客户端传递过来的消息，此时的消息就是一个入站消息。

**出站：**实现了ChannelOutboundHandler处理的消息称为出站，同理当服务端处理完消息之后相应客户端的时候，此时就会调用实现了ChannelOutboundHandler的实现处理，此时就是一个出站消息。如果是以客户端的角度来看是一样的逻辑。

还有一种理解入站出站的方式就是，根据ChannelPipeline中维护的双向链表来看，当事件流向从表头到表尾的时候就是入站，从表尾到表头的就是出站消息，这里需要从源码的角度去分析。EventLoop分析可知，请求的具体处理逻辑是在NioEventLoop的run方法中。跟踪read方法会调用pipeline.fireChannelRead(byteBuf)，也就是ChannelPipeline中fireChanelRead方法。继续跟踪AbstractChannelHandlerContext.invokeChannelRead(head, msg)，这里传递了ChannelPipeline中的表头head参数。

    private AbstractChannelHandlerContext findContextInbound(int mask) {
        AbstractChannelHandlerContext ctx = this;
        EventExecutor currentExecutor = executor();
        do {
            ctx = ctx.next;
        } while (skipContext(ctx, currentExecutor, mask, MASK_ONLY_INBOUND));
        return ctx;
    }

从上边代码可以看出，findContextInbound方法会寻找出一个合适INBOUD入站handler来处理读请求。也就是证明了入站是从表头开始查找合适的handler。

我们继续看看当服务端往客户端响应的时候，也就是服务端写数据的时候源码处理逻辑，也就是跟踪ChannelHandlerContext的write方法可以看到有这么一段代码

        final AbstractChannelHandlerContext next = findContextOutbound(flush ?
                (MASK_WRITE | MASK_FLUSH) : MASK_WRITE);
                
        private AbstractChannelHandlerContext findContextOutbound(int mask) {
        AbstractChannelHandlerContext ctx = this;
        EventExecutor currentExecutor = executor();
        do {
            ctx = ctx.prev;
        } while (skipContext(ctx, currentExecutor, mask, MASK_ONLY_OUTBOUND));
        return ctx;
    }        

从源码看，当服务端写数据的时候就会从当前的context中往前寻找一个合适的OUTBOUND出站的handler来处理写请求，也就是从表尾到表头的过程，这也就证明了出站是从表尾到表头的一个处理链。

三、ChannelHandler生命周期

ChannelHandler接口定义的方法有handlerAdded和handlerRemoved两个，也就是ChannelHandler的生命周期从add开始，remove结束。让我们看看源码中是怎样的一个过程对ChannelHandler的处理。

1. 回到bind()方法：首先调用initAndRegister()对channel进行初始化和注册。
2. init()方法里：会往NioServerSocketChannel的pipeline属性中添加一个ChannelInitializer的匿名对象，该对象的initChannel()方法会添加两个handler，一个是通过ServerBootstrap.handler()配置，另一个是ServerBootstrapAcceptor（前文分析可知这是用来处理请求的handler）。查看ChannelPipeline的addLast方法可以看到有这么一行代码callHandlerAdded0(newCtx);这个方法就是调用handler的handlerAdded方法，这就是生命周期的开始，也就是添加到pipeline链表中。
3. register(channel)：register0()中有这么行代码pipeline.fireChannelRegistered();也就是当channel注册成功之后，就会调用channelregistered方法。注册完成之后就调用doBind0()方法进行端口绑定。
4. doBind0()方法：只有端口绑定完成之后，此时channel才算激活状态，也就是系统会调用pipeline.fireChannelActive();方法。
5. 读：绑定结束，就开始接收来自客户的请求，前几节已经分析过了，此时会调用channelRead的方法，当读完成之后，紧接着就是调用channelReadComplete方法。
6. channel关闭。服务端和客户端完成数据交换后，就会调用close方法关闭通道，此时lose方法就会调用cfireChannelInactiveAndDeregister这个方法，一是执行channelInactive还有就是deregister(voidPromise())，deregister方法，会调用cancel方法去把当前的SelectionKey.cancel(),然后在调用fireChannelUnregistered()这个方法，这个方法主要做两件事，一是调用用户的channelUnregistered方法，一个是调用destroy()方法，destroy方法就是把当前的handler从链表中移除，然后调用handlerRemoved方法。

从上边分析可知ChannelHandler的生命周期过程是handlerAdded–>channelRegistered–>channelActive–>channelRead–>channelReadComplete–>channelInactive–>channelUnregistered–>handlerRemoved，这期间都会伴随着exceptionCaught方法进行异常捕获。

以上，有任何不对的地方，请指正，敬请谅解。