标签：nal 发送 channel 主题 回调 com this 组织 温习
精进篇：netty源码死磕5 - 揭开 ChannelHandler 的神秘面纱
1. 前言
2. Handler在经典Reactor中的角色
3. Handler在Netty中的坐标位置
4. Netty中Handler的类型
1.1. ChannelInboundHandler入站处理器
1.2. ChannelOutboundHandler出站处理器
5. 揭开Pipeline的神秘面纱
6. Handler的上下文环境
7. Handler的注册
7.1. 第一步：包裹
7.2. 加入链表并注册完成回调事件
7.3. 回调添加完成事件
8. 小结
Reactor模式是Netty的基础和灵魂，掌握了经典的Reactor模式实现，彻底掌握Netty就事半功倍了。《Reactor模式（netty源码死磕3）》对Reactor模式的经典实现，进行了详细介绍。作为本文的阅读准备，可以去温习一下。
Reactor模式的两个重要的组件，一个是Reactor反应器，在Netty中的对应的实现是EventLoop，在文章《EventLoop（netty源码死磕4）》中，已经有了非常详细的介绍。
此文聚焦于Reactor模式的另一个重要的组成部分Handler。
在Reactor经典模型中，Reactor查询到NIO就绪的事件后，分发到Handler，由Handler完成NIO操作和计算的操作。
Handler主要的操作为Channel缓存读、数据解码、业务处理、写Channel缓存，然后由Channel（代表client）发送到最终的连接终端。
经典的Reactor模式，更多在于演示和说明，仅仅是有一种浓缩和抽象。
由于Netty更多用于生产，在实际开发中的业务处理这块，主要通过Handler来实现，所以Netty中在Handler的组织设计这块，远远比经典的Reactor模式实现，要纷繁复杂得多。
在分析Handler之前，首先回顾一下Netty中的Channel。在《EventLoop（netty源码死磕4）》中，已经有详细的说明。一个Netty Channel对应于一个Client连接，内部封装了一个Java NIO SelectableChannel 可查询通道。
再回到Handler。
Hander的根本使命，就是处理Channel的就绪事件，根据就绪事件，完成NIO处理和业务操作。比方Channel读就绪时，Hander就开始读；Channel写就绪时，Hander就开始写。
从应用程序开发人员的角度来看，Netty的主要组件是ChannelHandler，所以，对ChannelHandler的分类，也是从应用开发的角度来的。
从应用程序开发人员的角度来看，数据有入站和出站两种类型。
这里的出站和入站，不是网络通信方面的入站和出站。而是相对于Netty Channel与Java NIO Channel而言的。
数据入站，指的是数据从底层的Java NIO channel到Netty的Channel。数据出站，指的是通过Netty的Channel来操作底层的 Java NIO chanel。
从入站和出战的角度出发，Netty中的ChannelHandler主要由两种类型，ChannelInboundHandler和ChannelOutboundHandler。
当Java NIO事件进站到Channel时，产生一的一系列事件将由ChannelHandler所对应的API处理。
当查询到Java NIO底层Channel的就绪事件时，通过一系列的ChannelInboundHandler处理器，完成底层就绪事件的处理。比方说底层连接建立事件、底层连接断开事件、从底层读写就绪事件等等。
啰嗦一下，入站（inbound）处理通常由底层Java NIO channel触发，主要事件如下：
1. 注册事件 fireChannelRegistered。
2. 连接建立事件 fireChannelActive。
3. 读事件和读完成事件 fireChannelRead、fireChannelReadComplete。
4. 异常通知事件 fireExceptionCaught。
5. 用户自定义事件 fireUserEventTriggered。
6. Channel 可写状态变化事件 fireChannelWritabilityChanged。
7. 连接关闭事件 fireChannelInactive。
当需要Netty Channel需要操作Java NIO底层Channel时，通过一系列的ChannelOutboundHandler处理器，完成底层操作。比方说建立底层连接、断开底层连接、从底层Java NIO通道读入、写入底层Java NIO通道等。ChannelOutboundHandler是一个接口，主要操作如下图所示：
啰嗦一下，出站（inbound） Handler通常是Netty channel操作底层Java NIO channel，主要操作如下：
1. 端口绑定 bind。
2. 连接服务端 connect。
3. 写事件 write。
4. 刷新时间 flush。
5. 读事件 read。
6. 主动断开连接 disconnect。
7. 关闭 channel 事件 close。
至此，Netty中的两大处理器的类型，就已经说得很清楚了。
再说说Handler和Channel的关系。
打个比方，如果Hander是太阳系的行星，那么Channel就是太阳系的恒星。Hander的服务对象和公转的轴心，就是Channel。
这可能是最为不恰当的一个比方，但是说的是事实。
一个Channel在数量上，肯定不止拥有一个Handler。 如何将杂乱无章的Handler，有序的组织起来呢？
来了一个Handler的装配器——Pipeline。
Pipeline是何方神圣呢？
先揭一下神秘面纱：
Netty中， 使用一个双向链表，将属于一个Channel的所有Handler组织起来，并且给这个双向链表封装在一个类中，再给这个类取了一个非常牛逼的名字，叫做ChannelPipeline。
为什么这个名字很牛逼呢？
实际上这里用了Java中一种非常重要的设计模式，Pipeline设计模式。后面将用专门的文章，来介绍这种牛逼模式。
回到主题：
一个Channel，仅仅一个ChannelPipeline。该pipeline在Channel被创建的时候创建。ChannelPipeline相当于是ChannelHandler的容器，它包含了一个ChannelHander形成的列表，且所有ChannelHandler都会注册到ChannelPipeline中。
在Netty的设计中，Handler是无状态的，不保存和Channel有关的信息。打个不恰当的比方，Handler就像国际雇佣军一样，谁给钱，给谁打仗。Handler的目标，是将自己的处理逻辑做得很完成，可以给不同的Channel使用。
与之不同的是，Pipeline是有状态的，保存了Channel的关系。
于是乎，Handler和Pipeline之间，需要一个中间角色，把他们联系起来。这个中间角色是谁呢？
它就是——ChannelHandlerContext 。
所以，ChannelPipeline 中维护的，是一个由 ChannelHandlerContext 组成的双向链表。这个链表的头是 HeadContext, 链表的尾是 TailContext。而无状态的Handler，作为Context的成员，关联在ChannelHandlerContext 中。在对应关系上，每个 ChannelHandlerContext 中仅仅关联着一个 ChannelHandler。
我们继续用源码说话。
Context的双向链表的主要代码，在 AbstractChannelHandlerContext类中。该类主要包含一个双向链表节点的前置和后置节点引用 prev、next，以及数据引用 handler，相当于链表数据结构中的 Node 节点。
部分关键源码节选如下：
// ChannelHandler 首位指针
final AbstractChannelHandlerContext head;
final AbstractChannelHandlerContext tail;
// pipeline 所属 channel
private final Channel channel;
private final ChannelFuture succeededFuture;
private final VoidChannelPromise voidPromise;
private final boolean touch = ResourceLeakDetector.isEnabled();
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;
}
Handler是如何注册到Pipeline中的呢？
加入到Pipeline之前，在Pipeline的基类DefaultChannelPipeline中，首先对Handler进行包裹。
代码如下：
// 使用 AbstractChannelHandlerContext 包裹 ChannelHandler
private AbstractChannelHandlerContext newContext(EventExecutorGroup group, String name, ChannelHandler handler) {
return new DefaultChannelHandlerContext(this, childExecutor(group), name, handler);
}
1. 构建了 AbstractChannelHandlerContext 节点，并加入到了链表尾部。
2. 如果 channel 尚未注册到 EventLoop，就添加一个任务到 PendingHandlerCallback 上，后续channel 注册完毕，再调用 ChannelHandler.handlerAdded。
3. 如果已经注册，马上调用 callHandlerAdded0 方法来执行 ChannelHandler.handlerAdded 注册完成的回调函数。
代码如下：
@Override
public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
final AbstractChannelHandlerContext newCtx;
synchronized (this) {
// 检查，若不是 Sharable，而且已经被添加到其他 pipeline，则抛出异常
checkMultiplicity(handler);
// 构建 AbstractChannelHandlerContext 节点
newCtx = newContext(group, filterName(name, handler), handler);
// 添加到链表尾部
addLast0(newCtx);
// registered 为 false 表示 channel 尚未注册到 EventLoop 上。
// 添加一个任务到 PendingHandlerCallback 上，后续注册完毕，再调用 ChannelHandler.handlerAdded
if (!registered) {
newCtx.setAddPending();
callHandlerCallbackLater(newCtx, true);
return this;
}
// registered 为 true，则立即调用 ChannelHandler.handlerAdded
EventExecutor executor = newCtx.executor();
// inEvent 用于判断当前线程是否是 EventLoop 线程。执行 ChannelHandler 时，必须在对应的 EventLoop 线程池中执行。
if (!executor.inEventLoop()) {
newCtx.setAddPending();
executor.execute(new Runnable() {
@Override
public void run() {
callHandlerAdded0(newCtx);
}
});
return this;
}
}
callHandlerAdded0(newCtx);
return this;
}
@Override
public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
final AbstractChannelHandlerContext newCtx;
synchronized (this) {
// 检查，若不是 Sharable，而且已经被添加到其他 pipeline，则抛出异常
checkMultiplicity(handler);
// 构建 AbstractChannelHandlerContext 节点
newCtx = newContext(group, filterName(name, handler), handler);
// 添加到链表尾部
addLast0(newCtx);
// registered 为 false 表示 channel 尚未注册到 EventLoop 上。
// 添加一个任务到 PendingHandlerCallback 上，后续注册完毕，再调用 ChannelHandler.handlerAdded
if (!registered) {
newCtx.setAddPending();
callHandlerCallbackLater(newCtx, true);
return this;
}
// registered 为 true，则立即调用 ChannelHandler.handlerAdded
EventExecutor executor = newCtx.executor();
// inEvent 用于判断当前线程是否是 EventLoop 线程。执行 ChannelHandler 时，必须在对应的 EventLoop 线程池中执行。
if (!executor.inEventLoop()) {
newCtx.setAddPending();
executor.execute(new Runnable() {
@Override
public void run() {
callHandlerAdded0(newCtx);
}
});
return this;
}
}
callHandlerAdded0(newCtx);
return this;
}
添加完成后，执行回调方法如下：
private void callHandlerAdded0(final AbstractChannelHandlerContext ctx) {
try {
ctx.handler().handlerAdded(ctx);
ctx.setAddComplete();
} catch (Throwable t) {
…….
}会执行handler的handlerAdded 方法，这是一个回调方法。添加完成后的回调代码，基本上写在这里。
至此，牛逼的Netty Handler和Netty Reactor 介绍完了。
对于Pipeline模式和基于Pipeline的Netty 入站和出站的事件传输机制，【疯狂创客圈】在后面的系列死磕文章，会做一个非常精彩的介绍。
标签：nal 发送 channel 主题 回调 com this 组织 温习
原文地址：https://www.cnblogs.com/crazymakercircle/p/9853586.html
