netty入门（一）

灰太狼 2021-12-18 12:45 358阅读 0赞

# 1. netty入门（一） #

## 1.1. 传统socket编程 ##

![751560-20190305110955033-209972831.png][]

1.  在任何时候都可能有大量的线程处于休眠状态，只是等待输入或者输出数据就绪，这可能算是一种**资源浪费**。
2.  需要**为每个线程的调用栈都分配内存**，其默认值大小区间为 64 KB 到 1 MB，具体取决于操作系统。
3.  即使 Java 虚拟机（JVM）在物理上可以支持非常大数量的线程，但是远在到达该极限之前，上下文切换所带来的开销就会带来麻烦

## 1.2. NIO ##

![751560-20190305112301600-1800444605.png][]

1.  class java.nio.channels.Selector 是Java 的非阻塞 I/O 实现的关键。它使用了事件通知 API以确定在一组非阻塞套接字中有哪些**已经就绪**能够进行 I/O 相关的操作。因为可以在任何的时间检查任意的读操作或者写操作的完成状态，所以如图 1-2 所示，**一个单一的线程便可以处理多个并发的连接**。

## 1.3. Netty核心组件 ##

### 1.3.1. Channel ###

它代表一个到实体（如一个硬件设备、一个文件、一个网络套接字或者一个能够执
    行一个或者多个不同的I/O操作的程序组件）的开放连接，如读操作和写操作

1.  目前，可以把 Channel 看作是传入（入站）或者传出（出站）**数据的载体**。因此，它可以  
    被打开或者被关闭，连接或者断开连接。

### 1.3.2. 回调 ###

1.  一个回调其实就是一个方法，一个指向已经被提供给另外一个方法的方法的引用。这使得后者可以在适当的时候调用前者。回调在广泛的编程场景中都有应用，而且也是在操作完成后通知相关方最常见的方式之一
2.  Netty 在内部使用了回调来处理事件；当一个回调被触发时，相关的事件可以被一个 interfaceChannelHandler 的实现处理。代码清单 1-2 展示了一个例子：当一个新的连接已经被建立时，  
    ChannelHandler 的 channelActive()回调方法将会被调用，并将打印出一条信息  
    ![751560-20190305113908038-1307892950.png][]
    
    ### 1.3.3. Future ###
3.  Future 提供了另一种在操作完成时通知应用程序的方式。这个对象可以看作是一个异步操作的结果的占位符；它将在未来的某个时刻完成，并提供对其结果的访问
4.  JDK 预置了 interface java.util.concurrent.Future，但是其所提供的实现，只允许手动检查对应的操作是否已经完成，或者一直阻塞直到它完成。这是非常繁琐的，所以 **Netty提供了它自己的实现——ChannelFuture，用于在执行异步操作的时候使用**。
5.  ChannelFuture提供了几种额外的方法，这些方法使得我们能够注册一个或者多个ChannelFutureListener实例。监听器的回调方法operationComplete()，将会在对应的操作完成时被调用
6.  简而 言之 ，由ChannelFutureListener提供的通知机制消除了手动检查对应的操作是否完成的必要
7.  每个 Netty 的出站 I/O 操作都将返回一个 ChannelFuture；也就是说，它们都**不会阻塞**。正如我们前面所提到过的一样，Netty 完全是异步和事件驱动的。  
    ![751560-20190305114425617-1289110722.png][]

### 1.3.4. 事件和 ChannelHandler ###

1.  Netty 使用不同的事件来通知我们状态的改变或者是操作的状态。这使得我们能够基于已经  
    发生的事件来触发适当的动作。这些动作可能是：
    
     *  记录日志；
     *  数据转换；
     *  流控制；
     *  应用程序逻辑
2.  每个事件都可以被分发给 ChannelHandler 类中的某个用户实现的方法。这是一个很好的将事件驱动范式直接转换为应用程序构件块的例子。  
    ![751560-20190305115155102-1832475869.png][]
3.  Netty 的 ChannelHandler 为处理器提供了基本的抽象，如图 1-3 所示的那些

## 1.4. 服务端核心流程 ##

![751560-20190305154124368-1174309774.png][]

![751560-20190305154033642-1825955764.png][]

*  EchoServerHandler 实现了业务逻辑；
 *  main()方法引导了服务器；
    
    引导过程中所需要的步骤如下：
    
     *  创建一个 ServerBootstrap 的实例以引导和绑定服务器；
     *  创建并分配一个 NioEventLoopGroup 实例以进行事件的处理，如接受新连接以及读/  
        写数据；
     *  指定服务器绑定的本地的 InetSocketAddress；
     *  使用一个 EchoServerHandler 的实例初始化每一个新的 Channel；
     *  调用 ServerBootstrap.bind()方法以绑定服务器

## 1.5. 客户端核心流程 ##

1.  Echo 客户端将会：

*  连接到服务器；
 *  发送一个或者多个消息；
 *  对于每个消息，等待并接收从服务器发回的相同的消息；
 *  关闭连接。  
    ![751560-20190305162511491-1319044955.png][]

![751560-20190305162542636-741235571.png][]

1.  流程
    
     *  为初始化客户端，创建了一个 Bootstrap 实例；
     *  为进行事件处理分配了一个 NioEventLoopGroup 实例，其中事件处理包括创建新的连接以及处理入站和出站数据；
     *  为服务器连接创建了一个 InetSocketAddress 实例；
     *  当连接被建立时，一个 EchoClientHandler 实例会被安装到（该 Channel 的）ChannelPipeline 中；
     *  在一切都设置完成后，调用 Bootstrap.connect()方法连接到远程节点；

## 1.6. Netty 的组件和设计 ##

### 1.6.1. Channel、EventLoop 和 ChannelFuture ###

*  Channel—Socket；
 *  EventLoop—控制流、多线程处理、并发；
 *  ChannelFuture—异步通知
    
    #### 1.6.1.1. Channel 接口 ####

1.  基本的 I/O 操作（bind()、connect()、read()和 write()）依赖于底层网络传输所提供的原语。
2.  Netty 的 Channel 接口所提供的 API，大大地降低了直接使用 Socket 类的复杂性。

#### 1.6.1.2. EventLoop 接口 ####

1.  EventLoop 定义了 Netty 的核心抽象，用于处理连接的生命周期中所发生的事件。
2.  图 3-1在高层次上说明了 Channel、EventLoop、Thread 以及 EventLoopGroup 之间的关系。  
    ![751560-20190305164036264-2094385727.png][]
3.  这些关系是：

*  一个 EventLoopGroup 包含一个或者多个 EventLoop；
 *  一个 EventLoop 在它的生命周期内只和一个 Thread 绑定；
 *  所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理；
 *  一个 Channel 在它的生命周期内只注册于一个 EventLoop；
 *  一个 EventLoop 可能会被分配给一个或多个 Channel

#### 1.6.1.3. ChannelFuture 接口 ####

1.  Netty 中所有的 I/O 操作都是异步的。因为一个操作可能不会立即返回，所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此，Netty 提供了ChannelFuture 接口，其 addListener()方法注册了一个 ChannelFutureListener，以便在某个操作完成时（无论是否成功）得到通知。

### 1.6.2. ChannelHandler 和 ChannelPipeline ###

#### 1.6.2.1. ChannelHandler 接口 ####

1.  从应用程序开发人员的角度来看，Netty 的主要组件是 ChannelHandler，它充当了所有处理入站和出站数据的应用程序逻辑的容器

#### 1.6.2.2. ChannelPipeline 接口 ####

1.  ChannelPipeline 提供了 ChannelHandler 链的容器，并定义了用于在该链上传播入站和出站事件流的 API。当 Channel 被创建时，它会被自动地分配到它专属的 ChannelPipeline。
2.  ChannelHandler 安装到 ChannelPipeline 中的过程如下所示：

*  一个ChannelInitializer的实现被注册到了ServerBootstrap中
 *  当 ChannelInitializer.initChannel()方法被调用时，ChannelInitializer将在 ChannelPipeline 中安装一组自定义的 ChannelHandler；
 *  ChannelInitializer 将它自己从 ChannelPipeline 中移除。

1.  图 3-3 说明了一个 Netty 应用程序中入站和出站数据流之间的区别。从一个客户端应用程序的角度来看，如果事件的运动方向是从客户端到服务器端，那么我们称这些事件为出站的，反之则称为入站的。  
    ![751560-20190305165012382-796213306.png][]

#### 1.6.2.3. 编码器和解码器 ####

1.  当你通过 Netty 发送或者接收一个消息的时候，就将会发生一次**数据转换**。入站消息会被解码；也就是说，从**字节转换为另一种格式**，通常是一个 Java 对象。
2.  如果是出站消息，则会发生相反方向的转换：它将从它的当前格式被编码为字节。这两种方向的转换的原因很简单：**网络数据总是一系列的字节**。

#### 1.6.2.4. 抽象类 SimpleChannelInboundHandler ####

1.  最常见的情况是，你的应用程序会利用一个 ChannelHandler 来接收解码消息，并对该数据应用业务逻辑。
2.  要创建一个这样的 ChannelHandler，你只需要扩展基类 SimpleChannelInboundHandler，其中 T 是你要处理的消息的 Java 类型 。

## 1.7. 传输 ##

1.  流经网络的数据总是具有相同的类型：**字节**。这些字节是如何流动的主要取决于我们所说的网络传输—一个帮助我们抽象底层数据传输机制的概念。
2.  ChannelHandler 的典型用途包括：

*  将数据从一种格式转换为另一种格式；
 *  提供异常的通知；
 *  提供 Channel 变为活动的或者非活动的通知；
 *  提供当 Channel 注册到 EventLoop 或者从 EventLoop 注销时的通知；
 *  提供有关用户自定义事件的通知

## 1.8. ByteBuf ##

1.  网络数据的**基本单位总是字节**。Java NIO 提供了 ByteBuffer 作为它的**字节容器**，但是这个类使用起来过于复杂，而且也有些繁琐
2.  Netty 的 ByteBuffer **替代品是 ByteBuf**，一个强大的实现，既解决了 JDK API 的局限性，又为网络应用程序的开发者提供了更好的 API。
3.  下面是一些 ByteBuf API 的优点：

*  它可以被用户自定义的**缓冲区类型扩展**；
 *  通过内置的**复合缓冲区类型**实现了透明的零拷贝；
 *  容量可以**按需增长**（类似于 JDK 的 StringBuilder）；
 *  在读和写这两种模式之间切换不需要调用 ByteBuffer 的 flip()方法；
 *  读和写使用了不同的索引；
 *  支持方法的**链式调用**；
 *  支持**引用计数**；
 *  支持池化

### 1.8.1. 如何工作 ###

1.  ByteBuf 维护了两个不同的索引：一个用于读取，一个用于写入。当你从 ByteBuf 读取时，它的readerIndex 将会被递增已经被读取的字节数。同样地，当你写入 ByteBuf 时，它的writerIndex 也会被递增。图 5-1 展示了一个空 ByteBuf 的布局结构和状态。  
    ![751560-20190306101311371-2008237802.png][]

### 1.8.2. ByteBuf 的使用模式 ###

#### 1.8.2.1. 堆缓冲区 ####

1.  最常用的 ByteBuf 模式是将数据存储在 JVM 的堆空间中。这种模式被称为支撑数组（backing array），它能在没有使用池化的情况下提供快速的分配和释放。这种方式，如代码清单5-1 所示，非常适合于有遗留的数据需要处理的情况。  
    ![751560-20190306101821595-901860518.png][]

#### 1.8.2.2. 直接缓冲区 ####

1.  直接缓冲区是另外一种 ByteBuf 模式。我们期望用于**对象创建的内存分配永远都来自于堆中**，但这并不是必须的——NIO 在 JDK 1.4 中引入的 ByteBuffer 类允许 JVM 实现通过本地调用来分配内存。这主要是为了避免在每次调用本地 I/O 操作之前（或者之后）将缓冲区的内容复制到一个中间缓冲区（或者从中间缓冲区把内容复制到缓冲区）。
2.  直接缓冲区的主要缺点是，相对于基于堆的缓冲区，它们的**分配和释放都较为昂贵**。如果你正在处理遗留代码，你也可能会遇到另外一个缺点：因为数据不是在堆上，所以你不得不进行一次复制，如代码清单 5-2 所示。

![751560-20190306102223559-1630091903.png][]

#### 1.8.2.3. 复合缓冲区 ####

1.  第三种也是最后一种模式使用的是复合缓冲区，它为多个 **ByteBuf 提供一个聚合视图**。在这里你可以根据需要添加或者删除 ByteBuf 实例，这是一个 JDK 的 ByteBuffer 实现完全缺失的特性。
2.  Netty 通过一个 ByteBuf 子类——CompositeByteBuf——实现了这个模式，它提供了一个**将多个缓冲区表示为单个合并缓冲区的虚拟表示**
3.  代码清单 5-3 展示了如何通过使用 JDK 的 ByteBuffer 来实现这一需求。创建了一个包含两个 ByteBuffer 的数组用来保存这些消息组件，同时创建了第三个 ByteBuffer 用来保存所有这些数据的副本。

![751560-20190306102541695-1755282306.png][]

1.  分配和复制操作，以及伴随着对数组管理的需要，使得这个版本的实现效率低下而且笨拙。代码清单 5-4 展示了一个使用了 CompositeByteBuf 的版本

![751560-20190306102705488-1146974635.png][]

1.  CompositeByteBuf 可能不支持访问其支撑数组，因此访问 CompositeByteBuf 中的数据类似于（访问）直接缓冲区的模式，如代码清单 5-5 所示。

![751560-20190306102811168-2129345696.png][]

### 1.8.3. Unpooled 缓冲区 ###

1.  可能某些情况下，你未能获取一个到 ByteBufAllocator 的引用。对于这种情况，Netty 提供了一个简单的称为 Unpooled 的工具类，它提供了静态的辅助方法来创建未池化的 ByteBuf实例。表 5-8 列举了这些中最重要的方法。

![751560-20190306103631250-1455172534.png][]

## 1.9. ChannelHandler和ChannelPipeline ##

### 1.9.1. ChannelHandler 家族 ###

#### 1.9.1.1. Channel 的生命周期 ####

1.  Interface Channel 定义了一组和 ChannelInboundHandler API 密切相关的简单但功能强大的状态模型

*  ChannelUnregistered Channel 已经被创建，但还未注册到 EventLoop
 *  ChannelRegistered Channel 已经被注册到了 EventLoop
 *  ChannelActive Channel 处于活动状态（已经连接到它的远程节点）。它现在可以接收和发送数据了
 *  ChannelInactive Channel 没有连接到远程节点

1.  Channel 的正常生命周期如图 6-1 所示。当这些状态发生改变时，将会生成对应的事件。这些事件将会被转发给 ChannelPipeline 中的 ChannelHandler，其可以随后对它们做出响应  
    ![751560-20190306104319549-1229442519.png][]

#### 1.9.1.2. ChannelHandler 的生命周期 ####

1.  表 6-2 中列出了 interface ChannelHandler 定义的生命周期操作，在 ChannelHandler被添加到 ChannelPipeline 中或者被从 ChannelPipeline 中移除时会调用这些操作。这些方法中的每一个都接受一个 ChannelHandlerContext 参数。

![751560-20190306104440342-1764054310.png][]

1.  Netty 定义了下面两个重要的 ChannelHandler 子接口：

*  ChannelInboundHandler——处理入站数据以及各种状态变化；
 *  ChannelOutboundHandler——处理出站数据并且允许拦截所有的操作。

#### 1.9.1.3. ChannelInboundHandler 接口 ####

![751560-20190306104801303-1189532527.png][]

1.  当某个 ChannelInboundHandler 的实现重写 channelRead()方法时，它将负责显式地释放与池化的 ByteBuf 实例相关的内存。Netty 为此提供了一个实用方法 ReferenceCountUtil.release()，如代码清单 6-1 所示。

![751560-20190306104928374-394704367.png][]

1.  Netty 将使用 WARN 级别的日志消息记录未释放的资源，使得可以非常简单地在代码中发现违规的实例。但是以这种方式管理资源可能很繁琐。一个更加简单的方式是使用SimpleChannelInboundHandler。代码清单 6-2 是代码清单 6-1 的一个变体，说明了这一点

![751560-20190306105146435-1506679664.png][]

#### 1.9.1.4. ChannelOutboundHandler 接口 ####

1.  出站操作和数据将由 ChannelOutboundHandler 处理。它的方法将被 Channel、ChannelPipeline 以及 ChannelHandlerContext 调用
2.  ChannelOutboundHandler 的一个强大的功能是可以**按需推迟操作或者事件**，这使得可以通过一些复杂的方法来处理请求。例如，如果到远程节点的写入被暂停了，那么你可以推迟冲刷操作并在稍后继续
3.  表6-4显示了所有由ChannelOutboundHandler本身所定义的方法（忽略了那些从ChannelHandler 继承的方法）。

![751560-20190306105643303-847840836.png][]

#### 1.9.1.5. ChannelHandler 适配器 ####

1.  你可以使用 ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter类作为自己的 ChannelHandler 的起始点。这两个适配器分别提供了 ChannelInboundHandler和ChannelOutboundHandler 的基本实现。  
    ![751560-20190306110028677-2022573247.png][]
2.  ChannelHandlerAdapter 还提供了实用方法 isSharable()。如果其对应的实现被标注为 Sharable，那么这个方法将返回 true，表示它可以被添加到多个 ChannelPipeline中

### 1.9.2. ChannelPipeline 接口 ###

1.  ChannelHandler 可以通过添加、删除或者替换其他的 ChannelHandler 来实时地修改  
    ChannelPipeline 的布局。  
    ![751560-20190306112040978-1309816402.png][]  
    ![751560-20190306112154503-561143095.png][]

转载于:https://www.cnblogs.com/sky-chen/p/10497166.html

[751560-20190305110955033-209972831.png]: /images/20211218/dc04afeb54c147488bf76e3aae4e579c.png
[751560-20190305112301600-1800444605.png]: /images/20211218/a806821ed3aa4852a9deb65e96a34fec.png
[751560-20190305113908038-1307892950.png]: /images/20211218/92c0fe8b1f2d4e6fa2c70874ae5d3093.png
[751560-20190305114425617-1289110722.png]: /images/20211218/a4bc825ad7d04191b0b46dc4a571ad2f.png
[751560-20190305115155102-1832475869.png]: /images/20211218/20d433127c7a4355971b553d223afca0.png
[751560-20190305154124368-1174309774.png]: /images/20211218/5ef2262bef2a4a4384f83ebf06811cec.png
[751560-20190305154033642-1825955764.png]: /images/20211218/7e65581ae7e348ea9b01bb6e10d207c5.png
[751560-20190305162511491-1319044955.png]: /images/20211218/9000fd49d3414438a6ee1728a16fa4ca.png
[751560-20190305162542636-741235571.png]: /images/20211218/d397b57cdd314406adf23a15a2e8fee2.png
[751560-20190305164036264-2094385727.png]: /images/20211218/222612eefe4d4de3bb88519f345f27bc.png
[751560-20190305165012382-796213306.png]: /images/20211218/dbd7a214ebcb4f0eaaba07ae38360048.png
[751560-20190306101311371-2008237802.png]: /images/20211218/d4bec5976f1f430c9e3f96f96eecd3e4.png
[751560-20190306101821595-901860518.png]: /images/20211218/10f430d838ca483b83c52e7fb1f70a98.png
[751560-20190306102223559-1630091903.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306102223559-1630091903.png
[751560-20190306102541695-1755282306.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306102541695-1755282306.png
[751560-20190306102705488-1146974635.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306102705488-1146974635.png
[751560-20190306102811168-2129345696.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306102811168-2129345696.png
[751560-20190306103631250-1455172534.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306103631250-1455172534.png
[751560-20190306104319549-1229442519.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306104319549-1229442519.png
[751560-20190306104440342-1764054310.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306104440342-1764054310.png
[751560-20190306104801303-1189532527.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306104801303-1189532527.png
[751560-20190306104928374-394704367.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306104928374-394704367.png
[751560-20190306105146435-1506679664.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306105146435-1506679664.png
[751560-20190306105643303-847840836.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306105643303-847840836.png
[751560-20190306110028677-2022573247.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306110028677-2022573247.png
[751560-20190306112040978-1309816402.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306112040978-1309816402.png
[751560-20190306112154503-561143095.png]: https://img2018.cnblogs.com/blog/751560/201903/751560-20190306112154503-561143095.png