第 6 章 ChannelHandler 相关

左手的ㄟ右手 2022-05-24 11:56 230阅读 0赞

# 概述 #

ChannelHandler 作为程序逻辑的核心部分，其地位是不可估量的。接下来我们将对它以及与它相关的一些组件进行详细的描述。

首先我们看一下如下这张图，对 ChannelHandler 相关组件之间的关系有一个比较直观的认识

![20180526232401402][]

从上图我们对 Channel 相关组件的关系有了一个大概的认识。接下我们对每一个进行详细说明

# 6.2 ChannelPipeLine #

对于每一个新创建的 Channel ，一定且只会被分配一个 ChannelPipeLine。这种一 一 对应的关系在 Channel 的生命周期内都是存在的。一个 ChannelPipeLine 由多个 ChannelHandler 组成，它就等价于一个 ChannelHandler 实例链。如下图，展示了一个典型同时具有入站和出站 ChannelHandler 的 ChannelPipeLine 布局

![20180527005542422][]

在 Netty 中总是将 ChannelPipeLine 的入站口——最先读取数据的处理器（上图中的左侧：1号）作为头部，而将出站口——最先写入数据的处理器（上图中的最右侧：5号）作为尾部。

从上图还可以得知：入站 ChannelHandler 和 出站 ChannelHandler 可以同时添加到 ChannelPipeLine 中，ChannelHandler 的排序与它们的添加次序有关。当一个入站事件在 ChannelPipeLine 中传播时，他会“自动”跳过处理出站事件的相关 ChannelHandler（也就是不相关的 Handler，如上图中的3、5）；对于出站事件类似。这里有个问题

**如何实现自动跳过不想关的处理器的？**

其实如果简单从代码实现层面来理解，需要两步走：

1. 确定该 Handler 是出站还是入站 Handler

由于入站 Handler 和 出站 Handler 传输数据使用的方法不一样，那自定义 Handler（selfHandler）只需要覆盖 ChannelHandlerAdapter 中不同的方法即可判断该 selfHandler 是出站还是入站事件的 Handler。例如，若 selfHandler 覆盖了 ChannelHandlerAdapter 中 channelRead(ChannelHandlerContext ctx, Object msg) 方法，则为入站 Handler；如  selfHandler 覆盖了 ChannelHandlerAdapter 中 write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) 方法，则为出站 Handler；若 selfHandler 同时覆盖了channelRead 和 write 两个方法，则 selfHandler 是同时可以处理出、入站事件的 Handler。

2. 通过 @Skip 来跳过对应的 Handler

如果确定好 selfChannelHandler 是出站 Handler 的时候，当上图中的 2 号 入站 Handler 传递消息到 3 号 selfChannelHandler （出站 Handler）的时候，由于 selfChannelHandler 没有实现对应的 channelRead 方法，所以会走 ChannelHandlerAdapter 的 默认实现方法，该默认实现方法有一 注解 @Skip（跳过），顾名思义，跳过该 handler。

## 6.2.1 修改 ChannelPipeLine ##

通过调用 ChannelPipeLine 的相关方法，我们可以灵活的控制 ChannelHandler 在ChannelPipeLine 的位置，从而可以控制业务逻辑。常用方法如下

addFirst（）、addBefore（）、addAfter（）、 addLast（）、 remove（）、replace（）。

总结说来

*      ChannelPipeLine 保存了与 Channel 相关联的所有 ChannelHandler
 *      ChannelPipeLine 可以根据需要添加或者删除 ChannelHandler 来动态修改
 *      ChannelPipeLine 有着丰富的 API 可以被调用，以相应出、入站事件

# 6.3 ChannelHandlerContext #

ChannelHandlerContext 是 ChannelPipeLine 和 ChannelHandler 之间的一种关联，主要功能就是管理它所关联的 ChannelHandler 与 同一个 ChannelPipeLine 中的 其他 ChannelHandler 之间的交互。

每当向 ChannelPipeLine 中添加 ChannelHandler 时，都会创建一个 ChannelHandlerContext 。在 ChannelPipeLine、Channel、ChannelHandlerContext 三个勒种接口中有些共同的方法。三个不同的接口调用同样一个方法来处理事件的时候，会有所不同：ChannelPipeLine、和Channel调用的处理事件的方法，该事件会沿着整个 ChannelPipeLine 传播，ChannelHandlerContext 调用同样的方法的时候，事件从下一个能处理该事件的 ChannelHandler 开始传播的。

针对 ChannelHandlerContext ，有以下两大特性：

ChannelHandlerContext 的方法会产生更短的事件流，应该尽可能的利用这个特性来获得性能的最大提升

ChannelHandlerContext 和 ChannelHandler 之间的关联（绑定）是永远不会变的，所以缓存它的引用是安全的

## 6.3.1 使用 ChannelHandlerContext ##

在 Netty 程序中，我们通过入站 Handler 处理完数据之后，一般会在最后收到事件流的入站 Handler 处理完逻辑后，往远端写一个响应消息。如下图

![20180527154522178][]

从图中可以看到事件A 最后来到 4 号入站 Hander，处理完之后，在 4 号 Handler 中写入以响应事件 B，写入的方法有三种

1. 通过 Channel 写入：channel.write（事件 B ）

事件流向为：4 号 ---> 5号 --->3 号 --->远端

2. 通过 ChannelPipeLine 写入：pipeline.write（事件 B）

事件流向为：4 号 ---> 5号 --->3 号 \--->远端

3. 通过 ChannelHandlerContext 写入：channelHandlerContext.write（事件 B ）

事件流向为：4 号 --->3 号 \--->远端

ChannelHandler 之间的事件流传递都是通过 ChannelHandlerContext 来实现的，从代码层面来看，其实就是调用了 ChannelHandlerContext 的 fireXXX（）方法来触发下一个 ChannelHandler 的 XXX（）方法。

## 6.3.2 ChannelHandler 和 ChannelHandlerContext 的高级用法 ##

1. 使用 @Sharable 标记共享 ChannelHandler

在多个 ChannelPipeLine 中安装同一个 ChannelHandler时，需要在该 ChannelHandler 上用 @Sharable 注解标记。在使用共享 ChannelHandler 的时候尤其要注意是否线程安全。其用法如下：

@Sharable public class SharableHandler extends ChannelHandlerAdapter{     // do something

}

共享 ChannelHandler 的目的在于统计一些共有的信息（比如系统访问次数）。

# 6.4 异常处理 #

## 6.4.1 入站异常 ##

对于出站异常，我们只需要继承 exceptionCaught 方法，在里面完成相应的异常处理逻辑即可

## 6.4.2 出站异常 ##

对于异常，通常的做法是：对调用给定的方法返回的 ChannelFuture 添加一个监听，待操作完成后，得到通知。典型做法如下

ChannelFuture future = channel.write(msg); future.addListener(new ChannelFutureListener()){ @Override public void operationComplete(ChannelFuture f){     if(!f.isSuccess()){          f.cause.printStackTrace();         f.channel().close;       }   } }

# 总结 #

本章主要学习了事件是如何在 ChannelHandler 之间进行传递的，以及对于一些异常的处理。下一章节讲学习 Netty 的 EventLoop 和 并发模型

[20180526232401402]: /images/20220524/44018314d6a64c34a8a3a0f57eedb5af.png
[20180527005542422]: /images/20220524/0f451dc29b234735841a12763bbfc043.png
[20180527154522178]: /images/20220524/41df28c2a9f4448eba0fe4ea71abb4e5.png