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的线程模型进行分析。