Netty学习笔记（四）--- ChannelHandler

在前面的文章中，通过对引导和线程的介绍，我们知道了如何配置、引导客户端和服务端程序，以及程序的线程模型。它们构建了应用程序运行的框架，但一个完整的网络应用程序还需要更多的内容，其中包括数据应该如何处理。Netty为此提供了一个强大功能组件ChannelHanlder接口，它允许用户自定义ChannelHandler的实现来处理传入和传出的数据。

在一款网络应用程序中，数据应该是其中最重要的部分，其他组件都是为了更方便有效的处理数据，所以作为处理数据的ChannelHandler组件应该算是Netty的核心组成部分。正如在前面的文章中的Echo应用程序，我们专门为服务器和客户端编写为ChannelHandler编写了实现类XXXXHandler，由此可见ChannelHandler的重要性。我们使用Netty时，绝大部分时间也都是写在这部分代码，所以了解它的一些机制和特性是很有必要的。

ChannelHandler家族

ChannelHandler作为Netty中Handler组件的根接口，其继承体系十分庞杂，有很多子类实现，具体的内容可参考api，下面会对其中的几个常用的实现进行介绍。

ChannelHandler接口

ChannelHandler接口中定义了三个生命周期操作，如下面的代码所示：

// 当把ChannelHandler添加到ChannelPipeline中时被调用
void handlerAdded(ChannelHandlerContext ctx) throws Exception;

// 当把ChannelHandler从ChannelPipeline中移除时被调用
void handlerRemoved(ChannelHandlerContext ctx) throws Exception;

// 当处理数据或事件的过程中，在ChannelPipeline中有错误产生时被调用
void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception;

如上面的类图所示，ChannelHandler有两个重要的接口：ChannelInboundHandler和ChannelOutboundHandler。

ChannelInboundHandler接口

ChannelInboundHandler作为处理入站事件以及各类状态变化的Handler实现的父接口，它扩展了父接口，新增了一些特有的回调方法。这些方法将会在数据被接收时或者与其对应的 Channel 状态发生改变时被调用。

// 当Channel已经注册到它的EventLoop并且能够处理I/O时被调用
void channelRegistered(ChannelHandlerContext ctx)
// 当Channel从它所关联的EventLoop注销并无法处理任何I/O时被调用
void channelUnregistered(ChannelHandlerContext ctx)
// 当Channel处于活动状态时被调用，Channel已经连接/绑定并且已经就绪
void channelActive(ChannelHandlerContext ctx)
// 当Channel离开活动状态并且不再连接它的远程节点时被调用
void channelInactive(ChannelHandlerContext ctx)
// 当Channel读取数据时被调用
void channelRead(ChannelHandlerContext ctx, Object msg)
// 当Channel上的一个读操作完成时被调用
void channelReadComplete(ChannelHandlerContext ctx)
// 当用户事件触发时被调用，因为一个POJO被传经了ChannelPipeline
void userEventTriggered(ChannelHandlerContext ctx, Object evt)
// 当Channel的可写状态改变时被调用
void channelWritabilityChanged(ChannelHandlerContext ctx)

可以注意到上面的每个方法都带了ChannelHandlerContext作为参数，具体作用是，在每个回调事件里面，处理完成之后，使用ChannelHandlerContext的fireChannelXXX方法来传递给下个ChannelHandler。

@Override
public void channelRegistered(ChannelHandlerContext ctx) throws Exception {
    ctx.fireChannelRegistered();
}

ChannelOutboundHandler接口

ChannelOutboundHandler是处理出站数据并且允许拦截所有的操作的Handler实现的父接口。它也对ChannelHandler接口进行了扩展，并定义了一些自身特有的方法。

// 当请求将Channel绑定在本地地址时被调用
void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise)
// 当请求将Channel连接到远程节点时被调用
void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise)
// 当请求将Channel从远程节点断开时被调用
void disconnect(ChannelHandlerContext ctx, ChannelPromise promise)
// 当请求关闭Channel时被调用
void close(ChannelHandlerContext ctx, ChannelPromise promise)
// 当请求将Channel从所关联的EventLoop上注销时被调用
void deregister(ChannelHandlerContext ctx, ChannelPromise promise)
// 当请求从Channel读取更多的数据时被调用
void read(ChannelHandlerContext ctx)
// 当请求通过Channel将数据写到远程节点时被调用
void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)
// 当请求通过Channel将入队数据冲刷到远程节点时被调用
void flush(ChannelHandlerContext ctx)

和上面类似的，在每个回调事件处理完成之后，需要向下一个ChannelHandler传递，不同的是，这里需要调用ChannelHandlerContext的write()方法向下传递。

ChannelHandler适配器

ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter这两个适配器类作为上面两个接口的实现类，分别实现了它们所有的方法。实际编程中我们总是以这两个类作为起点，继承它们并重写其中感兴趣的方法来编写适合自己的Handler。

从上面的类图可看出，这两个适配器实现类同时继承了ChannelHandlerAdapter抽象类，而后者提供了一个实用方法 isSharable()。如果其对应的实现被标注为 @Sharable，那么这个方法将返回 true，表示它可以被添加到多个 ChannelPipeline中。

@Sharable
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
       ....
    }
	...
}

对于@Sharable注解的详细内容，可以查看你真的了解Netty中@Sharable？，文章对@sharable注解的原理做了详细说明。

SimpleChannelInboundHandler

至此，只剩下SimpleChannelInboundHandler抽象类了，它继承了ChannelInboundHandlerAdaptor类，重写channelRead方法，并增加了channelRead0的抽象方法。

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    boolean release = true;
    try {
        if (acceptInboundMessage(msg)) {
            @SuppressWarnings("unchecked")
            I imsg = (I) msg;
            channelRead0(ctx, imsg);
        } else {
            release = false;
            ctx.fireChannelRead(msg);
        }
    } finally {
        if (autoRelease && release) {
            ReferenceCountUtil.release(msg);
        }
    }
}

protected abstract void channelRead0(ChannelHandlerContext ctx, I msg) throws Exception;

这里使用的是模板模式，将需要变化的逻辑放在抽象方法channelRead0(…)中，让子类根据自己的实现进行编写；将处理逻辑不变的内容写好在 channelRead(…)中，并在里面调用channelRead0(…)。

当我们继承SimpleChannelInboundHandler类时，将自定义逻辑写入channelRead0(…)中，当channelRead真正被触发调用时我们的逻辑才会被处理，然后根据需求执行ctx.fireChannelRead(msg)传递到下一个ChannelHandler或者执行ReferenceCountUtil.release(msg)自动进行资源释放。而直接继承ChannelInboundHandlerAdapter类，则需要负责显式地释放与池化的 ByteBuf 实例相关的内存。

关于SimpleChannelInboundHandler更全面的理解，可查看Netty源码：深入理解SimpleChannelInboundHandler。

ChannelHandler的主要作用是处理I/O事件或拦截I/O操作，并将事件转发到其所属ChannelPipeline中的下一个ChannelHandler。针对事件的转发方式以及事件的具体处理方式，会在后面的文章中介绍。

ChannelPipeline接口

ChannelPipeline的作用是将多个ChannelHandler链接在一起来让事件在其中传播处理。一个ChannelPipeline中可能不仅有入站处理器，还有出站处理器，入站处理器只会处理入站的事件，而出站处理器只会处理出站的数据。

下面展示了一个同时具有入站处理器和出站处理器的ChannelPipeline典型分布，省略了tail和head节点。

从上图可看出，ChannelPipeline相当于一个ChannelHandler的容器。如果一个入站事件被触发，它将被从ChannelPipeline 的头部开始一直被传播到Channel Pipeline 的尾端。一个出站I/O 事件将从ChannelPipeline 的最右边开始，然后向左传播。

在 ChannelPipeline 传播事件时，它会检查 ChannelPipeline 中的下一个 ChannelHandler 的类型是否和事件的运动方向相匹配。如果不匹配，ChannelPipeline 将跳过该ChannelHandler 并前进到下一个，直到它找到和该事件所期望的方向相匹配的为止。需要注意的是，如果一个ChannelHandler 同时实现了 ChannelInboundHandler 接口和 ChannelOutboundHandler 接口，就可以即处理进站事件，也处理出站事件了。

操作ChannelHandler

了解完上面的基本信息后，我们先从源码入手，了解ChannelPipeline的内部结构，看看其是如何实现的，下面是ChannelPipeline的实现类DefaultChannelPipeline的部分代码。

final class DefaultChannelPipeline implements ChannelPipeline {
    final AbstractChannelHandlerContext head;
    final AbstractChannelHandlerContext tail;
    
    public DefaultChannelPipeline(AbstractChannel channel) {
        if (channel == null) {
            throw new NullPointerException("channel");
        }
        this.channel = channel;

        tail = new TailContext(this);
        head = new HeadContext(this);

        head.next = tail;
        tail.prev = head;
    }
}

可以看到, 在 DefaultChannelPipeline 的构造方法中，将传入的 channel 赋值给字段 this.channel，这里需要说明下：对于每个新的通道，会创建一个新的ChannelPipeline并附加至通道。一旦连接建立，Channel和ChannelPipeline之间的耦合就是永久性的。Channel不能附加其他的ChannelPipeline或从ChannelPipeline分离。

接着又实例化了两个特殊的字段: tail 与 head，这两个字段是一个双向链表的头和尾。其实在 DefaultChannelPipeline 中，维护了一个以 AbstractChannelHandlerContext 为节点的双向链表，这个链表是 Netty 实现 Pipeline 机制的关键。

继续查看tail和head的源码：

static final class TailContext extends AbstractChannelHandlerContext implements ChannelInboundHandler
static final class HeadContext extends AbstractChannelHandlerContext implements ChannelOutboundHandler

它们继承AbstractChannelHandlerContext的同时，分别实现了ChannelInboundHandler和ChannelOutboundHandler，因此可以说它们既是ChannelHandlerContext，又是 ChannelHandlerContext，这也是为什么它们是事件或消息的处理起点的原因。

到这里，通过这个AbstractChannelHandlerContext类型的双向链表和头尾节点的双重属性，Channelpipeline是和ChannelHandler关联起来了，但是我们添加的普通ChannelHandler实现类呢？

回到我们是熟悉的引导代码中：

bootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
    @Override
    protected void initChannel(SocketChannel ch) throws Exception {
        ChannelPipeline pipeline = ch.pipeline();
		pipeline.addLast(new ServerHandler());
    }
});

这里我们添加了一个自定义的ChannelHandler实现类，追踪其实现流程，其中一个环节：

@Override
public ChannelPipeline addLast(EventExecutorGroup group, final String name, ChannelHandler handler) {
    synchronized (this) {
        checkDuplicateName(name);
        AbstractChannelHandlerContext newCtx = new DefaultChannelHandlerContext(this, group, name, handler);
        addLast0(name, newCtx);
    }
    return this;
}

这里创建了一个AbstractChannelHandlerContext的对象，并将我们添加的ChannelHandler实现类作为参数。查看该构造函数：

DefaultChannelHandlerContext(
    DefaultChannelPipeline pipeline, EventExecutorGroup group, String name, ChannelHandler handler) {
    super(pipeline, group, name, isInbound(handler), isOutbound(handler));
    if (handler == null) {
        throw new NullPointerException("handler");
    }
    this.handler = handler;
}

再回到addLast(EventExecutorGroup group, final String name, ChannelHandler handler)中，继续向下执行，进入addLast0(name, newCtx)方法中：

private void addLast0(final String name, AbstractChannelHandlerContext newCtx) {
    checkMultiplicity(newCtx);
    AbstractChannelHandlerContext prev = tail.prev;
    newCtx.prev = prev;
    newCtx.next = tail;
    prev.next = newCtx;
    tail.prev = newCtx;
	// 省略部分代码
}

和我们熟悉的单向链表添加数据的方式类似，这里将新创建ChannelHandlerContext实现类，添加到双向链表中，至此我们明白了，每当添加一个ChannelHandler实现时，系统就会创建一个ChannelHandlerContext实例与之关联，我们添加ChannelHandler的过程，实际就是向ChannelPipeline中添加一个ChannelHandlerContext实例，只不过该实例内部包裹着一个自定义Channel Handler实例对象。

至此，我们自定义的ChannelHandler的成功添加到ChannelPipeline中。

当然，ChannelPipeline还提供了一系列方法，我们可以通过它们动态的添加、删除、替换其中的ChannelHandler，以满足不同的业务需求，这种机制极大的提高Netty的灵活性。

// 将ChannelHandler添加到ChannelPipeline起始位置
public ChannelPipeline addFirst（...）
// 将ChannelHandler添加到ChannelPipeline末尾位置
public ChannelPipeline addLast (...)
// 将ChannelHandler添加到指定的ChannelHandler之前
public ChannelPipeline addBefore (...)
// 将ChannelHandler添加到指定的ChannelHandler之后
public ChannelPipeline addAfter (...)
// 将一个 ChannelHandler 从 ChannelPipeline中移除
public ChannelPipeline remove (...)
// 将 ChannelPipeline中的一个 ChannelHandler 替换为另一个 ChannelHandler
public Channelpipeline replace (...)

下面通过代码来进行演示：

ChannelPipeline pipeline = ch.pipeline();
// 创建一个新的handler实例作为"handler1"添加到pipeline中
pipeline.addLast("handler1", new FirstHandler());
// 创建一个新的handler实例添加到pipeline中，它将被放置在handler1的前面
pipeline.addFirst("handler2", new SecondHandler());
// 创建一个新的handler实例添加到pipeline中，它将被放置在handler1的后面
pipeline.addAfter("hander1", "handler3", new ThirdHandler());
// 通过名称删除"handler3"
pipeline.remove("handler3");
// 创建一个新的handler实例，并替换掉名称为"handler2"的handler对象
pipeline.replace("handler2", "handler4", new FourthHanlder());

上面这些方法还有很多重载方法，具体内容可参考API。

inbound和outbound

再次回到创建AbstractChannelHandlerContext对象的代码中：

private final ChannelHandler handler;

DefaultChannelHandlerContext(
    DefaultChannelPipeline pipeline, EventExecutorGroup group, String name, ChannelHandler handler) {
    super(pipeline, group, name, isInbound(handler), isOutbound(handler));
    if (handler == null) {
        throw new NullPointerException("handler");
    }
    this.handler = handler;
}
@Override
public ChannelHandler handler() {
    return handler;
}
private static boolean isInbound(ChannelHandler handler) {
    return handler instanceof ChannelInboundHandler;
}
private static boolean isOutbound(ChannelHandler handler) {
    return handler instanceof ChannelOutboundHandler;
}

这里不单将ChannelHandler和ChannelHandlerContext关联在一起，还有两个重要的字段需要注意：inbound和outbound。

通过下面的两个方法isInbound(ChannelHandler handler)和isOutbound(ChannelHandler handler)可以知道，如果当前自定义的ChannelHandler对象实现了ChannelInboundHandler接口，则该对象为进站处理器，此时关联的ChannelHandlerContext对象的inbound=true，outbound=false；反之，该对象为出站处理器，与之关联的ChannelHandlerContext的inboun=false，outbound=true。这两个字段有什么作用呢？

上面我们提到：在 ChannelPipeline 传播事件时，它会检查 ChannelPipeline 中的下一个 ChannelHandler 的类型是否和事件的运动方向相匹配。ChannelPipeline 中的事件传播是通过ChannelHandlerContext调用相应的方法展开的，而其中就有检查函数findContextInbound()和findContextOutbound()。

// 这里只看最关键的代码,其他代码删掉
// 进站
public ChannelHandlerContext fireChannelRead(final Object msg) {
    final AbstractChannelHandlerContext next = findContextInbound();
}
// 出站
private void write(Object msg, boolean flush, ChannelPromise promise) {
    AbstractChannelHandlerContext next = findContextOutbound();
}

可以看出，两个方法的返回值next就是下一个符合条件的ChannelHandler对象，分别进入两个方法查看：

// 查找下一个进站处理器
private AbstractChannelHandlerContext findContextInbound() {
    AbstractChannelHandlerContext ctx = this;
    do {
        ctx = ctx.next;
    } while (!ctx.inbound);
    return ctx;
}
// 查找下一个出站处理器
private AbstractChannelHandlerContext findContextOutbound() {
    AbstractChannelHandlerContext ctx = this;
    do {
        ctx = ctx.prev;
    } while (!ctx.outbound);
    return ctx;
}

上面的逻辑很简单，就是对inbound和outbound进行判断，如果当前ChannelHandlerContext的inbound或outbound符合要求就返回。这样就通过inbound和outbound两个字段，将I/O事件传递到了合适的ChannelHandler上了。

**需要注意：**ChannelHandlerContext 有很多的方法，其中一些方法也存在于 Channel 和 ChannelPipeline 本身上，但是有一点重要的不同。如果调用 Channel 或者 ChannelPipeline 上的这些方法，它们将沿着整个 ChannelPipeline 进行传播。而调用位于 ChannelHandlerContext上的相同方法，则将从当前所关联的 ChannelHandler 开始，并且只会传播给位于该ChannelPipeline 中的下一个处理该事件ChannelHandler。