Netty：ChannelPipeline和ChannelHandler为什么会鬼混在一起？

矫情吗；* 2024-03-26 21:03 72阅读 0赞

## 前言 ##

> **数据流**是编程范式中的其中一种，何为数据流?

数据流具有**无穷数据源**、**数据流向**的特点：

*  无穷数据源：你无法预估你需要处理的数据流，你也不知道什么时候会产生数据
 *  数据流向：数据传递具有顺序性

在网络编程中，客户端想要跟服务器进行数据传递，首先就要通过三次握手建立`传输通道`，绑定好端口，此后通过这个socket进行数据传输。

当通道关闭后，如果想要建立连接，还需再次由客户端发起建立连接的请求，所以后面演进了使用`长连接`的方式来优化连接频繁地建立和销毁。

在网络编程中，`Channel`就是干这个事情的。

![format_png][]

类似于NIO的Channel，Netty提供了自己的`Channel`，使得更符合自身框架，叫做`ChannelPiple`。

## Channel ##

> JDK的NIO类库种Channel分2种：
> 
>  *  客户端的：SockerChannel
>  *  服务端的：ServerSocketChannel

![format_png 1][]

`Unsafe`是一个内部接口，**聚合在Channel种协助进行网络读写相关的操作**。

Unsafe本身是作为**Channel的一个内部辅助类**来用的，其实并不应该被Netty框架的上层使用者使用，所以是被命名为Unsafe

### Unsafe ###

> 是Channel内部的一个内部实现类，是一个接口类型

![format_png 2][]

**他不应该被用户代码直接调用，而是由实际负责IO的读写线程来调用**。这也是他的名字`Unsafe`的含义。

#### Unsafe中基础方法 ####

registry方法

> 作用：**将Channel注册到EventLoop的多路复用器上**

为了**避免多线程并发操作Channe**l的问题，这里还需要做并发处理

判断当前线程是否是Channel对应的NioEventLoop线程

*  如果是，则直接执行调用`#register0`执行注册逻辑
 *  如果不是，则以包成`Runnable`丢给**NioEventLoop**那边线程池的任务队列里去等待执行

![format_png 3][]

bind方法

> **给Channel绑定对应的Socket**
> 
>  *  对于服务端，用于绑定监听端口
>  *  对于客户端，用于指定客户端Channel的本地绑定Socker地址

write方法

> 把消息添加到唤醒发送数组：**ChannelOutboundBuffer**里面，并不是真正的写Channel，`flush`才是把消息写进Channel

![format_png 4][]

### ChannelPipeline功能说明 ###

> io.netty.channel.Channel是`Netty`**网络操作抽象类**，里面聚合了JDK的Channel对象

可以Channel理解为操作网络的一个对象，委派角色，他聚合了一组功能，包括但不限于：

*  **网络的读写**
 *  **客户端的发起连接、主动关闭连接、链路关闭**
 *  **获取双方通信的地址**
 *  …

#### JDK原生Channel ####

> JDK 也有NIO原生的Channel，但是Netty是另起炉灶自己抽象出来一个新的Channel，那这里又要讲讲，为什么不用原生JDK的东西了

1.  JDK的**SocketChannel**和**ServerSocketChannel**主要职责是负责**网络IO**操作。由于他们是`SPI`类接口，所以通过继承SPI功能类来扩展其功能难度大
    
    ***SPI和API的区别！还不懂的赶紧去复习，面试常考内容！***

![format_png 5][]

1.  Netty的Channel能够跟Netty的整体架构融合在一起，**跟架构亲和力更足**。
2.  **自定义Channel**，功能实现更加灵活（感觉这个才是最重要的）

> Netty的Channel设计理念

1.  在`Channel`接口层，采用`Facade`（外观模式）进行统一封装，**相当于一个聚合了一个JDK原生Channel的一个操作对象**
2.  为SocketChannel、ServerSocketChannel提供**统一的视图**，公共功能在父类中实现，子类实现更为具体的功能
3.  具体实现**采用聚合而非包含的方式**，将相关的功能聚合在Channel种，由Channel**统一负责分配和调度**。

#### 网络读写操作 ####

> 网络IO操作会触发`ChannelPipeline`中对应的事件方法

Neety是基于**事件驱动**，当`Channel`进行IO操作时，会产生对应的IO事件，然后**驱动事件在ChannelPipeline中传播**，最后**由ChannelHandler对事件进行拦截和处理**，不关心的事件可以直接忽略。

采用**事件驱动**的方式，有很多优点：

*  首先可以避免监听者列表过长，触发一次事件，采用**顺序遍历**性能会线性下降
 *  采用事件驱动可以很轻松**通过事件来划分事件拦截切面**，效果等价于`AOP`，甚至比他性能更高

**网络IO操作**直接调用`DefaultChannelPipeline`的相关方法，由前者中对应的`ChannelHandler`来进行逻辑处理。

#### AbstractChannel网络IO操作源码实现 ####

成员变量：

*  `SelectableChannel`：用于设置参数和进行IO操作
 *  `readInterestOp`：代表了**JDK SelectionKey**的**OP\_READ**
 *  `SelectionKey`：用**volatile**修饰，由于Channel会面临**多个业务线程并发写操作**，所以为了能让其他线程对其感知变化，所以使用volatile保证可见性

Channel的注册

> doRegister，把Channel注册到EventLoop中

![format_png 6][]

可以看到第二个参数`ops`，代表感兴趣的事件，doRegistry的时候直接传了个0，代表对任何事件都不感兴趣

![format_png 7][]

Channel对哪些事件感兴趣呢，比如：

*  `OP_READ` = 1 << 0； 读操作位
 *  `OP_WRITE` = 1 << 2；写操作位
 *  `OP_CONNECT` = 1 << 3；客户端连接服务端，建立连接操作
 *  `OP_ACCEPT` = 1 << 4；服务端接受客户端连接，成功建立连接操作

第三个参数是把自己`this`传过去了，这是为了能让触发事件的时候返回`SelectionKey`。

**根据SelectionKey是可以在多路复用器拿到对应感兴趣的Channel对象**，然后去进行处理。

## ChannelPipeline ##

### ChannelPipeline和ChannelHandler ###

> `ChannelPipleine`和`ChannelHandler`机制类似于**Servlet**和**Filter**过滤器

本质上是**责任链模式**的实现。

**Servlet Filter**能够以**声明式**的方法插入到HTTP请求处理过程中。用于**拦截请求和响应**，实现对请求的**前置处理**和**后置处理**。

Netty的Channel过滤器实现原理跟Servlet Filter机制一致，它将Channel的数据管道抽象成：`ChannelPipeline`。

![format_png 8][]

数据在`ChannelPipeline`中流动和传递，`ChannelPipeline`中持有IO事件拦截器`ChannelHandler`的**链表**。

意味着：**`ChannelHandler`可以对IO事件进行拦截和处理**

`ChannelHandler`是**可插拔式**的，并且我们可以通过**新增或者删除**`ChannelHandler`来实现不同业务逻辑，

### ChannelPipeline功能说明 ###

> ChannelPipeline是ChannelHandler的容器
> 
> 负责ChannelHandler的管理和**事件拦截与调度**

主要是：**负责事件的分发和预处理**

一个消息被ChannelPipeline的ChannelHandler链拦截和处理的全过程：

![format_png 9][]

1.  底层的SocketChannel `#read`方法读取ByteBuf，触发ChannelRead事件（`OP_READ`），由IO线程`NioEventLoop`调用ChannelPipeline的`#fireChannelRead`方法，将消息（ByteBuf）传输到**ChannelPipeline**中
2.  消息依次被添加好的ChannelHandler链处理，首先是HeadHandler，然后是ChannelHandler1、ChannelHandler2….，**任何Handler都可以中断消息的传递，也就是他们都可以把消息丢掉**。
    
    注意：这里是先是被`HeadHandler`处理，后面是反过来，**是有顺序的**
3.  ChannelHandlerContext的`#write`方法发送消息，消息从`TailHandler`开始，途径ChannelHandlerN，ChannelHandlerN-1….
    
    最终被添加到**消息发送缓冲区中**，等待刷新（`flush`）和发送（`write`）

> 注意：**这里为什么是具有顺序性地处理**，因为有些ChanelHandler就有**顺序性**，比如解码那些，需要先将ByteBuf数据解析成对象，然后再将对象二次解码成pojo对象。

Netty中的事件分为：`inbound`事件和`outbound`事件，**图中左半边对应inboud事件，右半边对应outbound事件**。

*  `inbound`：由外部触发的事件，应用程序以外的，并非应用程序自己请求的。比如某个socket有数据读取进来了，有Channel注册到Eventloop上了
 *  `outbound`：由应用程序主动请求而触发的事件，比如向某个socket写入数据，或从某个socket读取数据

**ChannelInboundHandler**处理`inboud`事件

**ChannelOutboundHandler**处理`outbound`事件

> 误区：区分inboud、outbound并不是简单的IO流，而是**触发事件的源头**

## 总结 ##

本篇简单介绍了JDK自带的`Channel`以及`Unsafe`其内部的一个实现类。并且从`Unsafe`的职责来更好的理解它这个名字的含义。

Netty提供的`ChannelPipeline`内部聚合了一个`ChannelHandler`链表。`ChannelPipeline`负责网络IO事件中的调度，而`ChannelHandler`则是负责拦截，如果是对应感兴趣的事件则处理，否则抛给下一个`ChannleHandler`。

粗略地讲了一下ChannelHandler为什么要基于**责任链**的设计模式，做成链表的形式。

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/8d12a550abbf43b48c383543d68719b9.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/83f039a9289f4c8c8ae6f9fc6e7aac09.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/039c12edc2f5488c8074cffb9fd9eceb.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/65c8b3550cc44cc0ac6c67cd16a29c7f.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/bc32a0e8f45c4719a2f74e5998476a6e.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/60ac4582a7e44e3dabed77d41b47f99e.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/dbb699b13b574fa0897566bdf7340f41.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/0f9a8246d6524b2594c35109a418e7f4.png
[format_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/f55e7382e55a46ef8e195f26bf4136a8.png
[format_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/55c7d9912d5c471fab91a963e675d001.png