Netty 各组件的原理分析（九）

悠悠 2022-10-29 12:29 160阅读 0赞

今天我们对 Netty 各组件的原理进行分析 ，主要有： **Channel** **、** **EventLoop(Group)** **和**  **ChannelFuture等。**

Netty  网络抽象的代表对比类似：

Channel—Socket；

EventLoop—控制流、多线程处理、并发；

ChannelFuture—异步通知。

Channel  和  EventLoop  关系如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

***一、Channel***  ***接口***

基本的  I/O  操作（ bind() 、 connect() 、 read() 和  write() ）依赖于底层网络传输所提供的原语。在基于 Java  的网络编程中，其基本的构造是类  Socket 。 Netty  的  Channel  接口所提供 的 API ，被用于所有的  I/O  操作。大大地降低了直接使用  Socket  类的复杂性。此外， Channel 也是拥有许多预定义的、专门化实现的广泛类层次结构的根。 由于 Channel  是独一无二的，所以为了保证顺序将  Channel  声明为  java.lang.Comparable 的一个子接口。因此，如果两个不同的 Channel  实例都返回了相同的散列码，那么

AbstractChannel  中的  compareTo() 方法的实现将会抛出一个  Error 。

1、Channel  的生命周期4种状态

ChannelUnregistered  ： Channel  已经被创建，但还未注册到  EventLoop

ChannelRegistered  ： Channel  已经被注册到了  EventLoop

ChannelActive  ： Channel  处于活动状态（已经连接到它的远程节点）。它现在可以接 收和发送数据了

ChannelInactive  ： Channel  没有连接到远程节点当这些状态发生改变时，将会生成对应的事件。这些事件将会被转发给 ChannelPipeline 中的 ChannelHandler ，其可以随后对它们做出响应。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

2、最重要  Channel  的方法

eventLoop ： 返回分配给  Channel  的  EventLoop

pipeline ： 返回分配给  Channel  的  ChannelPipeline

isActive ： 如果  Channel  是活动的，则返回  true 。活动的意义可能依赖于底层的传输。

例如，一个  Socket  传输一旦连接到了远程节点便是活动的，而一个  Datagram  传输一旦被 打开便是活动的。

localAddress ： 返回本地的  SokcetAddress

remoteAddress ： 返回远程的  SocketAddress

write ： 将数据写到远程节点。这个数据将被传递给  ChannelPipeline ，并且排队直到它被冲刷

flush ： 将之前已写的数据冲刷到底层传输，如一个  Socket

writeAndFlush ： 一个简便的方法，等同于调用  write() 并接着调用  flush()

***二、EventLoop***  ***和***  ***EventLoopGroup***

回想一下我们在  NIO  中是如何处理我们关心的事件的？在一个  while  循环中  select  出事 件，然后依次处理每种事件。我们可以把它称为事件循环，这就是 EventLoop 。 interface io.netty.channel. EventLoop 定义了  Netty  的核心抽象，用于处理网络连接的生命周期中所发 生的事件。 io.netty.util.concurrent 包构建在  JDK  的  java.util.concurrent  包上。而  io.netty.channel  包 中的类，为了与 Channel  的事件进行交互，扩展了这些接口 / 类。一个  EventLoop  将由一个 永远都不会改变的 Thread  驱动，同时任务（ Runnable  或者  Callable ）可以直接提交给 EventLoop 实现，以立即执行或者调度执行。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

根据配置和可用核心的不同，可能会创建多个  EventLoop  实例用以优化资源的使用，并 且单个 EventLoop  可能会被指派用于服务多个  Channel 。 Netty 的  EventLoop  在继承了  ScheduledExecutorService  的同时，只定义了一个方法， parent()。在  Netty 4  中，所有的  I/O  操作和事件都由已经被分配给了  EventLoop  的那个  Thread 来处理。

1、任务调度

偶尔，你将需要调度一个任务以便稍后（延迟）执行或者周期性地执行。例如，你可能 想要注册一个在客户端已经连接了 5  分钟之后触发的任务。一个常见的用例是，发送心跳 消息到远程节点，以检查连接是否仍然还活着。如果没有响应，你便知道可以关闭该 Channel 了。

2、线程管理

在内部，当提交任务到如果 **（** 当前）调用线程正是支撑  EventLoop  的线程，那么所提交 的代码块将会被（直接）执行。否则，EventLoop  将调度该任务以便稍后执行，并将它放入到内部队列中。当 EventLoop  下次处理它的事件时，它会执行队列中的那些任务 / 事件。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

3、线程的分配

服务于  Channel  的  I/O  和事件的  EventLoop  则包含在  EventLoopGroup  中。 异步传输实现只使用了少量的 EventLoop （以及和它们相关联的  Thread ），而且在当前

的线程模型中，它们可能会被多个  Channel  所共享。这使得可以通过尽可能少量的  Thread  来 支撑大量的 Channel ，而不是每个  Channel  分配一个  Thread 。 EventLoopGroup  负责为每个 新创建的 Channel  分配一个  EventLoop 。在当前实现中，使用顺序循环（ round-robin ）的方 式进行分配以获取一个均衡的分布，并且相同的 EventLoop  可能会被分配给多个  Channel 。 一旦一个 Channel  被分配给一个  EventLoop ，它将在它的整个生命周期中都使用这个 EventLoop（以及相关联的  Thread ）。请牢记这一点，因为它可以使你从担忧你的 ChannelHandler 实现中的线程安全和同步问题中解脱出来。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

需要注意，

EventLoop  的分配方式对  ThreadLocal  的使用的影响。因为一个  EventLoop  通常会被用于支撑多个 Channel ，所以对于所有相关联的  Channel  来说， ThreadLocal  都将是

一样的。这使得它对于实现状态追踪等功能来说是个糟糕的选择。然而，在一些无状态的上 下文中，它仍然可以被用于在多个 Channel  之间共享一些重度的或者代价昂贵的对象，甚至是事件。

***三、ChannelFuture***  ***接口***

Netty  中所有的  I/O  操作都是异步的。因为一个操作可能不会立即返回，所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此，Netty  提供了  ChannelFuture  接口， 其 addListener() 方法注册了一个  ChannelFutureListener ，以便在某个操作完成时（无论是否成功）得到通知。可以将 ChannelFuture  看作是将来要执行的操作的结果的占位符。它究竟什么时候被执 行则可能取决于若干的因素，因此不可能准确地预测，但是可以肯定的是它将会被执行。

**四、ChannelHandler 相关接口**

***1、ChannelHandler***  ***接口***

从应用程序开发人员的角度来看， Netty  的主要组件是  ChannelHandler ，它充当了所有 处理入站和出站数据的应用程序逻辑的容器。ChannelHandler  的方法是由网络事件触发的。 事实上，ChannelHandler  可专门用于几乎任何类型的动作，例如将数据从一种格式转换为另 外一种格式，例如各种编解码，或者处理转换过程中所抛出的异常。

举例来说， ChannelInboundHandler  是一个你将会经常实现的子接口。这种类型的 ChannelHandler 接收入站事件和数据，这些数据随后将会被你的应用程序的业务逻辑所处理。 当你要给连接的客户端发送响应时，也可以从 ChannelInboundHandler  直接冲刷数据然后输 出到对端。应用程序的业务逻辑通常实现在一个或者多个 ChannelInboundHandler  中。 这种类型的 ChannelHandler  接收入站事件和数据，这些数据随后将会被应用程序的业务逻辑所处理。

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

ChannelInboundHandler ——处理入站数据以及各种状态变化；

ChannelOutboundHandler ——处理出站数据并且允许拦截所有的操作。

***2、ChannelInboundHandler***  ***接口***

下面列出了接口  ChannelInboundHandler  的生命周期方法。这些方法将会在数据被接收时或者与其对应的 Channel  状态发生改变时被调用。正如我们前面所提到的，这些方法和 Channel 的生命周期密切相关。

**channelRegistered**  当  Channel  已经注册到它的  EventLoop  并且能够处理  I/O  时被调用。

**channelUnregistered**  当  Channel  从它的  EventLoop  注销并且无法处理任何  I/O  时被调用。

**channelActive**  当  Channel  处于活动状态时被调用； Channel  已经连接 / 绑定并且已经就绪。

**channelInactive**  当  Channel  离开活动状态并且不再连接它的远程节点时被调用。

**channelReadComplete**  当  Channel  上的一个读操作完成时被调用。

**channelRead**  当从  Channel  读取数据时被调用。

**ChannelWritabilityChanged**  当 Channel 的可写状态发生改变时被调用。可以通过调用  Channel  的  isWritable() 方法 来检测 Channel  的可写性。与可写性相关的阈值可以通过Channel.config().setWriteHighWaterMark()和  Channel.config().setWriteLowWaterMark() 方法来设置

**userEventTriggered**  当  ChannelnboundHandler.fireUserEventTriggered() 方法被调用时被调用。

***3、ChannelOutboundHandler***  ***接口***

出站操作和数据将由  ChannelOutboundHandler  处理。它的方法将被  Channel 、 Channel- Pipeline 以及  ChannelHandlerContext  调用。

所有由  ChannelOutboundHandler  本身所定义的方法：

**bind(ChannelHandlerContext,SocketAddress,ChannelPromise)** 当请求将 Channel  绑定到本地地址时被调用

**connect(ChannelHandlerContext,SocketAddress,SocketAddress,ChannelPromise)** 当请求将 Channel  连接到远程节点时被调用

**disconnect(ChannelHandlerContext,ChannelPromise)** 当请求将 Channel  从远程节点断开时被调用

**close(ChannelHandlerContext,ChannelPromise)**  当请求关闭  Channel  时被调用

**deregister(ChannelHandlerContext,ChannelPromise)** 当请求将 Channel  从它的  EventLoop  注销时被调用

**read(ChannelHandlerContext)**  当请求从  Channel  读取更多的数据时被调用

**flush(ChannelHandlerContext)**  当请求通过  Channel  将入队数据冲刷到远程节点时被调用

**write(ChannelHandlerContext,Object,ChannelPromise)**  当请求通过  Channel  将数据写到远程节点时被调用

***4、ChannelHandler***  ***的适配器***

有一些适配器类可以将编写自定义的  ChannelHandler  所需要的工作降到最低限度，因 为它们提供了定义在对应接口中的所有方法的默认实现。因为你有时会忽略那些不感兴趣的 事件，所以 Netty  提供了抽象基类  ChannelInboundHandlerAdapter  和 ChannelOutboundHandlerAdapter。 你可以使用 ChannelInboundHandlerAdapter  和  ChannelOutboundHandlerAdapter  类作为 自己的 ChannelHandler  的起始点。这两个适配器分别提供了  ChannelInboundHandler  和 ChannelOutboundHandler 的基本实现。通过扩展抽象类  ChannelHandlerAdapter ，它们获得 了它们共同的超接口 ChannelHandler  的方法。 ChannelHandlerAdapter 还提供了实用方法  isSharable() 。如果其对应的实现被标注为 Sharable，那么这个方法将返回  true ，表示它可以被添加到多个  ChannelPipeline 。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

***5、资源管理和***  ***SimpleChannelInboundHandler***

回想一下我们在  NIO  中是如何接收和发送网络数据的？都是首先创建了一个  Buffer ，应 用程序中的业务部分和 Channel  之间通过  Buffer  进行数据的交换：

//获得关心当前事件的channel
     SocketChannel sc = (SocketChannel) key.channel();
     //创建ByteBuffer，并开辟一个1M的缓冲区
       ByteBuffer buffer = ByteBuffer.allocate(1024);
      //读取请求码流，返回读取到的字节数
      int readBytes = sc.read(buffer);

Netty 在处理网络数据时，同样也需要  Buffer ，在  Read  网络数据时由  Netty  创建  Buffer ， Write 网络数据时  Buffer  往往是由业务方创建的。不管是读和写， Buffer  用完后都必须进行 释放，否则可能会造成内存泄露。 在 Write  网络数据时，可以确保数据被写往网络了， Netty  会自动进行  Buffer  的释放， 但是如果 Write  网络数据时，我们有  outBoundHandler  处理了  write() 操作并丢弃了数据，没 有继续往下写，要由我们负责释放这个 Buffer ，就必须调用  ReferenceCountUtil.release  方法， 否则就可能会造成内存泄露。 在 Read 网络数据时，如果我们可以确保每个  InboundHandler  都把数据往后传递了，也 就是调用了相关的 fireChannelRead  方法， Netty  也会帮我们释放，同样的，如果我们有 InboundHandler 处理了数据，又不继续往后传递，又不调用负责释放的 ReferenceCountUtil.release 方法，就可能会造成内存泄露。 但是由于消费入站数据是一项常规任务，所以 Netty  提供了一个特殊的被 称为 SimpleChannelInboundHandler  的  ChannelInboundHandler  实现。这个实现会在数 据被 channelRead0() 方法消费之后自动释放数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

同时系统为我们提供的各种预定义  Handler  实现，都实现了数据的正确处理，所以我们 自行在编写业务 Handler  时，也需要注意这一点： **要么继续传递，要么自行释放** 。

**五、ChannelPipeline**  **和**  **ChannelHandlerContext**

***1、ChannelPipeline***  ***接口***

当  Channel  被创建时，它将会被自动地分配一个新的  ChannelPipeline 。这项关联是永久 性的；Channel  既不能附加另外一个  ChannelPipeline ，也不能分离其当前的。在  Netty  组件 的生命周期中，这是一项固定的操作，不需要开发人员的任何干预。 使得事件流经 ChannelPipeline  是  ChannelHandler  的工作，它们是在应用程序的初始化

或者引导阶段被安装的。这些对象接收事件、执行它们所实现的处理逻辑，并将数据传递给 链中的下一个 ChannelHandler 。它们的执行顺序是由它们被添加的顺序所决定的。

***2、ChannelHandler***  ***的生命周期***

在  ChannelHandler  被添加到  ChannelPipeline  中或者被从  ChannelPipeline  中移除时会调 用下面这些方法。这些方法中的每一个都接受一个 ChannelHandlerContext  参数。

**handlerAdded**  当把  ChannelHandler  添加到  ChannelPipeline  中时被调用。

**handlerRemoved**  当从  ChannelPipeline  中移除  ChannelHandler  时被调用。

**exceptionCaught**  当处理过程中在  ChannelPipeline  中有错误产生时被调用。

***3、ChannelPipeline***  ***中***  ***ChannelHandler***

入站和出站  ChannelHandler  可以被安装到同一个  ChannelPipeline  中。如果一个消息或 者任何其他的入站事件被读取，那么它会从 ChannelPipeline  的头部开始流动，最终，数据 将会到达 ChannelPipeline  的尾端，届时，所有处理就都结束了。 数据的出站运动（即正在被写的数据）在概念上也是一样的。在这种情况下，数据将从

ChannelOutboundHandler  链的尾端开始流动，直到它到达链的头部为止。在这之后，出站 数据将会到达网络传输层，这里显示为 Socket 。通常情况下，这将触发一个写操作。如果将两个类别的ChannelHandler 都混合添加到同一个 ChannelPipeline  中会发生什么。 虽然 ChannelInboundHandle  和  ChannelOutboundHandle  都扩展自  ChannelHandler ，但是 Netty 能区分  ChannelInboundHandler  实现和  ChannelOutboundHandler  实现，并确保数据只 会在具有相同定向类型的两个 ChannelHandler  之间传递。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][]

***4、ChannelPipeline***  ***上的方法***

**addFirst** **、** **addBefore** **、** **addAfter** **、** **addLast** 将一个 ChannelHandler  添加到  ChannelPipeline  中

**remove**  将一个  ChannelHandler  从  ChannelPipeline  中移除

**replace**  将  ChannelPipeline  中的一个  ChannelHandler  替换为另一个  ChannelHandler

**get**  通过类型或者名称返回  ChannelHandler

**context**  返回和  ChannelHandler  绑定的  ChannelHandlerContext

**names**  返回  ChannelPipeline  中所有  ChannelHandler  的名称 ChannelPipeline 的  API  公开了用于调用入站和出站操作的附加方法。

***5、ChannelHandlerContext***

通过使用作为参数传递到每个方法的  **ChannelHandlerContext** ，事件可以被传递给当前 ChannelHandler 链中的下一个  ChannelHandler 。虽然这个对象可以被用于获取底层的 Channel，但是它主要还是被用于写出站数据。 ChannelHandlerContext 代表了  ChannelHandler  和  ChannelPipeline  之间的关联，每当有 ChannelHandler 添加到  ChannelPipeline  中时，都会创建  ChannelHandlerContext 。 ChannelHandlerContext 的主要功能是管理它所关联的  ChannelHandler  和在同一个 ChannelPipeline 中的其他  ChannelHandler  之间的交互。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8][]

ChannelHandlerContext  有很多的方法，其中一些方法也存在于  Channel  和 Channel-Pipeline 本身上， **但是有一点重要的不同。** 如果调用 Channel  或者 ChannelPipeline  上

的这些方法，它们将沿着整个  ChannelPipeline  进行传播。而调用位于  ChannelHandlerContext 上的相同方法，则将从当前所关联的  ChannelHandler  开始，并且只会传播给位于该 ChannelPipeline 中的下一个（入站下一个，出站上一个）能够处理该事件的  ChannelHandler 。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9][]

**ChannelHandlerContext**  **的**  **API**

**alloc**  返回和这个实例相关联的  Channel  所配置的  ByteBufAllocator

**bind**  绑定到给定的  SocketAddress ，并返回  ChannelFuture

**channel**  返回绑定到这个实例的  Channel

**close**  关闭  Channel ，并返回  ChannelFuture

**connect**  连接给定的  SocketAddress ，并返回  ChannelFuture

**deregister**  从之前分配的  EventExecutor  注销，并返回  ChannelFuture

**disconnect**  从远程节点断开，并返回  ChannelFuture

**executor**  返回调度事件的  EventExecutor

**fireChannelActive**  触发对下一个  ChannelInboundHandler  上的  channelActive() 方法（已 连接）的调用

**fireChannelInactive**  触发对下一个  ChannelInboundHandler  上的  channelInactive() 方法 （已关闭）的调用

**fireChannelRead**  触发对下一个  ChannelInboundHandler  上的  channelRead() 方法（已接 收的消息）的调用

**fireChannelReadComplete**  触发对下一个  ChannelInboundHandler  上的

channelReadComplete() 方法的调用

**fireChannelRegistered**  触发对下一个  ChannelInboundHandler  上的

fireChannelRegistered() 方法的调用

**fireChannelUnregistered**  触发对下一个  ChannelInboundHandler  上的

fireChannelUnregistered() 方法的调用

**fireChannelWritabilityChanged**  触发对下一个  ChannelInboundHandler  上的

fireChannelWritabilityChanged() 方法的调用

**fireExceptionCaught**  触发对下一个  ChannelInboundHandler  上的

fireExceptionCaught(Throwable) 方法的调用

**fireUserEventTriggered**  触发对下一个  ChannelInboundHandler  上的 fireUserEventTriggered(Object evt)方法的调用 **handler**  返回绑定到这个实例的  ChannelHandler

**isRemoved**  如果所关联的  ChannelHandler  已经被从  ChannelPipeline  中移除则返回  true

**name**  返回这个实例的唯一名称

**pipeline**  返回这个实例所关联的  ChannelPipeline

**read**  将数据从  Channel  读取到第一个入站缓冲区；如果读取成功则触发一个 channelRead 事件，并（在最后一个消息被读取完成后）通知  ChannelInboundHandler  的

channelReadComplete(ctx) 方法

**write**  通过这个实例写入消息并经过  ChannelPipeline

**writeAndFlush**  通过这个实例写入并冲刷消息并经过  ChannelPipeline

当使用  ChannelHandlerContext  的  API  的时候，有以下两点：

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

2、如同我们在本节开头所解释的一样，相对于其他类的同名方法， ChannelHandlerContext 的方法将产生更短的事件流，应该尽可能地利用这个特性来获得最大的性能。

**六、选择合适的内置通信传输模式**

**NIO**  io.netty.channel.socket.nio  使用  java.nio.channels  包作为基础 —— 基于选择器的方 式

**Epoll**  io.netty.channel.epoll  由  JNI  驱动的  epoll() 和非阻塞  IO 。这个传输支持只有在 Linux 上可用的多种特性，如  SO\_REUSEPORT ，比  NIO  传输更快，而且是完全非阻塞的。将 NioEventLoopGroup 替换为  EpollEventLoopGroup  ， 并且将  NioServerSocketChannel.class  替 换为 EpollServerSocketChannel.class  即可。

**OIO**  io.netty.channel.socket.oio  使用  java.net  包作为基础 —— 使用阻塞流

**Local**  io.netty.channel.local  可以在  VM  内部通过管道进行通信的本地传输

**Embedded**  io.netty.channel.embedded Embedded  传输，允许使用  ChannelHandler  而又 不需要一个真正的基于网络的传输。在测试 ChannelHandler  实现时非常有用

**七、引导**  **Bootstrap**

网络编程里，“服务器”和“客户端”实际上表示了不同的网络行为；换句话说，是监 听传入的连接还是建立到一个或者多个进程的连接。 因此，有两种类型的引导：一种用于客户端（简单地称为 Bootstrap ），而另一种 （ServerBootstrap ）用于服务器。无论你的应用程序使用哪种协议或者处理哪种类型的数据， 唯一决定它使用哪种引导类的是它是作为一个客户端还是作为一个服务器。

比较  **Bootstrap**  类

![20210214231344953.png][]

ServerBootstrap  将绑定到一个端口，因为服务器必须要监听连接，而  Bootstrap  则是由 想要连接到远程节点的客户端应用程序所使用的。 第二个区别可能更加明显。引导一个客户端只需要一个 EventLoopGroup ，但是一个 ServerBootstrap 则需要两个（也可以是同一个实例）。 因为服务器需要两组不同的 Channel 。第一组将只包含一个  ServerChannel ，代表服务器 自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含所有已创建的用来处理 传入客户端连接（对于每个服务器已经接受的连接都有一个）的 Channel 。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10][]

与  ServerChannel  相关联的  EventLoopGroup  将分配一个负责为传入连接请求创建 Channel 的  EventLoop 。一旦连接被接受，第二个  EventLoopGroup  就会给它的  Channel  分配 一个 EventLoop 。

**在引导过程中添加多个**  **ChannelHandler**

Netty  提供了一个特殊的  ChannelInboundHandlerAdapter  子类：

public abstract class ChannelInitializer<C extends Channel> extends ChannelInboundHandlerAdapter

它定义了下面的方法：

protect ed abstract void initChannel(C ch) throws Exception;

这个方法提供了一种将多个  ChannelHandler  添加到一个  ChannelPipeline  中的简便方法。 你只需要简单地向 Bootstrap  或  ServerBootstrap  的实例提供你的  ChannelInitializer  实现即 可，并且一旦 Channel  被注册到了它的  EventLoop  之后，就会调用你的  initChannel() 版本。 在该方法返回之后，ChannelInitializer  的实例将会从  ChannelPipeline  中移除它自己。

**ChannelOption**

ChannelOption  的各种属性在套接字选项中都有对应。

1 、 ChannelOption.SO\_BACKLOG

ChannelOption.SO\_BACKLOG  对应的是  tcp/ip  协议  listen  函数中的  backlog  参数，函数 listen(int socketfd,int backlog)用来初始化服务端可连接队列， 服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接，多 个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，backlog  参 数指定了队列的大小

2 、 ChannelOption.SO\_REUSEADDR

ChanneOption.SO\_REUSEADDR  对应于套接字选项中的  SO\_REUSEADDR ，这个参数表示允 许重复使用本地地址和端口， 比如，某个服务器进程占用了 TCP  的  80  端口进行监听，此时再次监听该端口就会返回 错误，使用该参数就可以解决问题，该参数允许共用该端口，这个在服务器程序中比较常使 用，比如某个进程非正常退出，该程序占用的端口可能要被占用一段时间才能允许其他进程 使用，而且程序死掉以后，内核一需要一定的时间才能够释放此端口，不设置 SO\_REUSEADDR 就无法正常使用该端口。

3 、 ChannelOption.SO\_KEEPALIVE

Channeloption.SO\_KEEPALIVE  参数对应于套接字选项中的  SO\_KEEPALIVE ，该参数用于设 置 TCP  连接，当设置该选项以后，连接会测试链接的状态，这个选项用于可能长时间没有数 据交流的连接。当设置该选项以后，如果在两小时内没有数据的通信时，TCP  会自动发送一个活动探测数据报文。

4 、 ChannelOption.SO\_SNDBUF  和  ChannelOption.SO\_RCVBUF

ChannelOption.SO\_SNDBUF  参数对应于套接字选项中的  SO\_SNDBUF ，

ChannelOption.SO\_RCVBUF  参数对应于套接字选项中的  SO\_RCVBUF  这两个参数用于操作接 收缓冲区和发送缓冲区的大小，接收缓冲区用于保存网络协议站内收到的数据，直到应用程 序读取成功，发送缓冲区用于保存发送数据，直到发送成功。

5 、 ChannelOption.SO\_LINGER

ChannelOption.SO\_LINGER  参数对应于套接字选项中的  SO\_LINGER,Linux  内核默认的处理 方式是当用户调用 close （）方法的时候，函数返回，在可能的情况下，尽量发送数据，不 一定保证会发生剩余的数据，造成了数据的不确定性，使用 SO\_LINGER  可以阻塞  close() 的调 用时间，直到数据完全发送

6 、 ChannelOption.TCP\_NODELAY

ChannelOption.TCP\_NODELAY  参数对应于套接字选项中的  TCP\_NODELAY, 该参数的使用 与 Nagle  算法有关， Nagle  算法是将小的数据包组装为更大的帧然后进行发送，而不是输入 一次发送一次, 因此在数据包不足的时候会等待其他数据的到了，组装成大的数据包进行发 送，虽然该方式有效提高网络的有效负载，但是却造成了延时，而该参数的作用就是禁止使 用 Nagle  算法，使用于小数据即时传输，于  TCP\_NODELAY  相对应的是  TCP\_CORK ，该选项是 需要等到发送的数据量最大的时候，一次性发送数据，适用于文件传输。

**八、ByteBuf 详解**

1、ByteBuf API  的优点：

1)、它可以被用户自定义的缓冲区类型扩展；

2)、通过内置的复合缓冲区类型实现了透明的零拷贝；

3)、容量可以按需增长（类似于  JDK  的  StringBuilder ）；

4)、在读和写这两种模式之间切换不需要调用  ByteBuffer  的  flip() 方法； 读和写使用了不同的索引；

5)、支持方法的链式调用；

6)、支持引用计数；

7)、支持池化。

ByteBuf  维护了两个不同的索引，名称以  read  或者  write  开头的  ByteBuf  方法，将会 推进其对应的索引，而名称以 set  或者  get  开头的操作则不会。 如果打算读取字节直到 readerIndex  达到和  writerIndex  同样的值时会发生什么。在那 时，你将会到达“可以读取的”数据的末尾。就如同试图读取超出数组末尾的数据一样，试 图读取超出该点的数据将会触发一个 IndexOutOf-BoundsException 。 可以指定 ByteBuf  的最大容量。试图移动写索引（即  writerIndex ）超过这个值将会触发 一个异常。（默认的限制是 Integer.MAX\_VALUE 。）

***2、使用模式***

1）堆缓冲区

最常用的  ByteBuf  模式是将数据存储在  JVM  的堆空间中。这种模式被称为支撑数组 （backing array ），它能在没有使用池化的情况下提供快速的分配和释放。可以由  hasArray() 来判断检查 ByteBuf  是否由数组支撑。如果不是，则这是一个直接缓冲区。

2）直接缓冲区

直接缓冲区是另外一种  ByteBuf  模式。

直接缓冲区的主要缺点是，相对于基于堆的缓冲区，它们的分配和释放都较为昂贵。

3）复合缓冲区

复合缓冲区  CompositeByteBuf ，它为多个  ByteBuf  提供一个聚合视图。比如  HTTP  协议， 分为消息头和消息体，这两部分可能由应用程序的不同模块产生，各有各的 ByteBuf ，将会 在消息被发送的时候组装为一个 ByteBuf ，此时可以将这两个  ByteBuf  聚合为一个 CompositeByteBuf，然后使用统一和通用的  ByteBuf API  来操作。

***3、分配***

如何在我们的程序中获得  ByteBuf  的实例，并使用它呢？ Netty  提供了两种方式

1、ByteBufAllocator  接口

Netty  通过  interface ByteBufAllocator  分配我们所描述过的任意类型的  ByteBuf  实例。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11][]

![20210214231439851.png][]

可以通过  Channel （每个都可以有一个不同的  ByteBufAllocator  实例）或者绑定到 ChannelHandler 的  ChannelHandlerContext  获取一个到  ByteBufAllocator  的引用。

![20210214231459585.png][]

Netty  提供了两种  ByteBufAllocator  的实现： PooledByteBufAllocator  和 Unpooled-ByteBufAllocator。前者池化了  ByteBuf  的实例以提高性能并最大限度地减少内存碎

片。后者的实现不池化  ByteBuf  实例，并且在每次它被调用时都会返回一个新的实例。 Netty4.1 默认使用了  PooledByteBufAllocator 。

2、Unpooled  缓冲区

Netty  提供了一个简单的称为  Unpooled  的工具类，它提供了静态的辅助方法来创建未 池化的 ByteBuf  实例。

buffer()  返回一个未池化的基于堆内存存储的  ByteBuf

directBuffer() 返回一个未池化的基于直接内存存储的  ByteBuf

wrappedBuffer()  返回一个包装了给定数据的  ByteBuf

copiedBuffer()  返回一个复制了给定数据的  ByteBuf

Unpooled  类还可用于  ByteBuf  同样可用于那些并不需要  Netty  的其他组件的非网络项目。

***3、随机访问索引*** ***/*** ***顺序访问索引*** ***/*** ***读写操作***

如同在普通的  Java  字节数组中一样， ByteBuf  的索引是从零开始的：第一个字节的索 引是 0 ，最后一个字节的索引总是  capacity() - 1 。使用那些需要一个索引值参数 ( **随机访问** , 也即是数组下标) 的方法（的其中）之一来访问数据既不会改变  readerIndex  也不会改变 writerIndex。如果有需要，也可以通过调用  readerIndex(index) 或者 writerIndex(index) 来手动 移动这两者。**顺序访问** 通过索引访问 有两种类别的读/ 写操作：

get() 和  set() 操作，从给定的索引开始，并且保持索引不变； get+ 数据字长 （bool.byte,int,short,long,bytes ） read()和  write() 操作，从给定的索引开始，并且会根据已经访问过的字节数对索引 进行调整。

**更多的操作**

isReadable()  如果至少有一个字节可供读取，则返回  true isWritable()  如果至少有一个字节可被写入，则返回  true

readableBytes() 返回可被读取的字节数

writableBytes()  返回可被写入的字节数

capacity()  返回  ByteBuf  可容纳的字节数。在此之后，它会尝试再次扩展直到达到

maxCapacity()

maxCapacity()  返回  ByteBuf  可以容纳的最大字节数

hasArray()  如果  ByteBuf  由一个字节数组支撑，则返回  true

array()  如果  ByteBuf  由一个字节数组支撑则返回该数组；否则，它将抛出一个 UnsupportedOperationException 异常

***4、可丢弃字节***

可丢弃字节的分段包含了已经被读过的字节。通过调用  discardReadBytes() 方法，可以丢 弃它们并回收空间。这个分段的初始大小为 0 ，存储在  readerIndex  中，会随着  read  操作的 执行而增加（get\* 操作不会移动  readerIndex ）。 缓冲区上调用 discardReadBytes() 方法后，可丢弃字节分段中的空间已经变为可写的了。 频繁地调用 discardReadBytes() 方法以确保可写分段的最大化，但是请注意，这将极有可能会 导致内存复制，因为可读字节必须被移动到缓冲区的开始位置。建议只在有真正需要的时候 才这样做，例如，当内存非常宝贵的时候。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12][]

***5、可读字节***

ByteBuf  的可读字节分段存储了实际数据。新分配的、包装的或者复制的缓冲区的默认 的 readerIndex  值为  0 。

***6、可写字节***

可写字节分段是指一个拥有未定义内容的、写入就绪的内存区域。新分配的缓冲区的 writerIndex 的默认值为  0 。任何名称以  write  开头的操作都将从当前的  writerIndex  处开始 写数据，并将它增加已经写入的字节数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 13][]

***7、索引管理***

调用  markReaderIndex() 、 markWriterIndex() 、 resetWriterIndex() 和  resetReaderIndex() 来 标记和重置 ByteBuf  的  readerIndex  和  writerIndex 。 也可以通过调用 readerIndex(int) 或者  writerIndex(int) 来将索引移动到指定位置。试图将 任何一个索引设置到一个无效的位置都将导致一个 IndexOutOfBoundsException 。

可以通过调用  clear() 方法来将  readerIndex  和  writerIndex  都设置为  0 。注意，这并不会 清除内存中的内容。

***8、查找操作***

在  ByteBuf  中有多种可以用来确定指定值的索引的方法。最简单的是使用  indexOf() 方法。 较复杂的查找可以通过调用 forEachByte() 。 代码展示了一个查找回车符（\\r ）的例子。

![2021021423155862.png][]

***9、派生缓冲区***

派生缓冲区为  ByteBuf  提供了以专门的方式来呈现其内容的视图。这类视图是通过以下 方法被创建的：

duplicate() ；

slice() ；

slice(int, int) ；

Unpooled.unmodifiableBuffer(…) ；

order(ByteOrder) ；

readSlice(int) 。

每个这些方法都将返回一个新的  ByteBuf  实例，它具有自己的读索引、写索引和标记索 引。其内部存储和 JDK  的  ByteBuffer  一样也是共享的。

**ByteBuf**  复制 如果需要一个现有缓冲区的真实副本，请使用  copy() 或者  copy(int, int) 方 法。不同于派生缓冲区，由这个调用所返回的 ByteBuf  拥有独立的数据副本。

***10、引用计数***

引用计数是一种通过在某个对象所持有的资源不再被其他对象引用时释放该对象所持 有的资源来优化内存使用和性能的技术。Netty  在第  4  版中为  ByteBuf  引入了引用计数技术， interface ReferenceCounted。

***11、工具类***

**ByteBufUtil**  提供了用于操作  ByteBuf  的静态的辅助方法。因为这个  API  是通用的，并 且和池化无关，所以这些方法已然在分配类的外部实现。 这些静态方法中最有价值的可能就是 hexdump() 方法，它以十六进制的表示形式打印 ByteBuf 的内容。这在各种情况下都很有用，例如，出于调试的目的记录  ByteBuf  的内容。 十六进制的表示通常会提供一个比字节值的直接表示形式更加有用的日志条目，此外，十六 进制的版本还可以很容易地转换回实际的字节表示。 另一个有用的方法是 boolean equals(ByteBuf, ByteBuf) ，它被用来判断两个  ByteBuf  实例 的相等性。

***12、资源释放***

当某个  ChannelInboundHandler  的实现重写  channelRead() 方法时，它要负责显式地释放 与池化的 ByteBuf  实例相关的内存。 Netty  为此提供了一个实用方法

ReferenceCountUtil.release() Netty 将使用  WARN  级别的日志消息记录未释放的资源，使得可以非常简单地在代码 中发现违规的实例。但是以这种方式管理资源可能很繁琐。一个更加简单的方式是使用 SimpleChannelInboundHandler， SimpleChannelInboundHandler  会自动释放资源。

1 、对于入站请求， Netty  的  EventLoo  在处理  Channel  的读操作时进行分配  ByteBuf ，对 于这类 ByteBuf ，需要我们自行进行释放，有三种方式，或者使用

SimpleChannelInboundHandler ，或者在重写  channelRead() 方法使用 ReferenceCountUtil.release()或者使用  ctx.fireChannelRead  继续向后传递；

2 、对于出站请求，不管  ByteBuf  是否由我们的业务创建的，当调用了  write  或者 writeAndFlush 方法后， Netty  会自动替我们释放，不需要我们业务代码自行释放。

到此，Netty 各组件的原理分析完成，下篇分析粘包和半包的解决方案，敬请期待！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221024/2d879d9f91a7471eada6acb96718af24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221024/9c1c76308051472696d3aa04e6483846.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221024/a3f7298d1b664d0587b50588b2307ddb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221024/5f662c377e7d4d799a5c21c018a29912.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221024/66bd1fa807de4b6e8d445a6b05bf25a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221024/194b6ca1d6be489c8ec6a89a5dec65b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221024/3cfcc56fefc044cca95fc7b771b851ee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: /images/20221024/5fa7b58163bb4a98bfa2ddf2e8e095f2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8]: /images/20221024/b68f35b1361f43b7a7a85e2b14a5f373.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9]: /images/20221024/e45f5422bc354da79e5dfedff3d557f7.png
[20210214231344953.png]: /images/20221024/d39923eb6677498baadbaa4deb37f975.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10]: /images/20221024/c5b95b02b530444ba92f9fae3cf4dc17.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11]: /images/20221024/c0ed516b0e944ad3bfb1fc2d7d73ffc7.png
[20210214231439851.png]: /images/20221024/40be580d82b14a6da98a85e6cf36cc42.png
[20210214231459585.png]: /images/20221024/0291009d1da94e5c92e698cf4b611603.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12]: /images/20221024/960dbd9227a449378abb9cadc59be036.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 13]: /images/20221024/7d58108e84124e16b67db34568a0b56d.png
[2021021423155862.png]: /images/20221024/61103be49e724914b1617190d45cee60.png