Netty 的主要组件 | 易学教程

ByteBuf 组件

当我们进行数据传输的时候，往往需要使用到缓冲区，常用的缓冲区就是 JDK NIO类库提供的 Buffer组件，7 种基本数据类型 ( Boolean 除外 ) 都有自己的缓冲区实现。对于 NIO编程而言，我们主要使用的是 ByteBuffer。从功能角度而言，ByteBuffer 完全可以满足 NIO编程的需
要，但是由于 NIO编程的复杂性，ByteBuffer 也有其局限性，它的主要缺点如下。

ByteBuffer 长度固定，一旦分配完成，它的容量不能动态扩展和收缩，当需要编码的 POJO对象大于 ByteBuffer 的容量时，会发生索引越界异常；
ByteBuffer 只有一个标识位置的指针position，读写的时候需要手工调用 flip() 和 rewind() 等，使用者必须小心谨慎地处理这些 API，否则很容易导致程序处理失败；
ByteBuffer 的 API 功能有限，一些高级和实用的特性它不支持，需要使用者自己编程实现。

为了弥补这些不足，Netty 提供了自己的 ByteBuffer实现，即 ByteBuf, 下面我们看一下 ByteBuf 的原理和主要功能。

ByteBuf 工作原理

首先，ByteBuf 依然是个 Byte数组的缓冲区，它的基本功能应该与 JDK 的 ByteBuffer 一致，提供以下几类基本功能。

7 种 Java基本数据类型、byte 数组、ByteBuffer ( ByteBuf ) 等的读写；
缓冲区自身的 copy 和 slice 等；
设置网络字节序；
构造缓冲区实例；
操作位置指针等方法。
由于 JDK 的 ByteBuffer 已经提供了这些基础能力的实现，因此，Netty ByteBuf 的实现可以有两种策略。
参考 JDK ByteBuffer 的实现，增加额外的功能，解决原 ByteBuffer 的缺点；
聚合 JDK ByteBuffer，通过 Facade模式对其进行包装，可以减少自身的代码量，降低实现成本。

JDK ByteBuffer 由于只有一个位置指针用于处理读写操作，因此每次读写的时候都需要额外调用 flip() 和 clear() 等方法。而 Netty 提供了两个指针变量用于支持顺序读取和写入操作。readerIndex 用于标识读取索引，writerlndex 用于标识写入索引。两个位置指针将 ByteBuf缓冲区分割成三个区域，如下图所示。
在这里插入图片描述
调用 ByteBuf 的 read操作时，从 readerIndex 处开始读取。readerIndex 到 writerIndex 之间的空间为可读的字节缓冲区；从 writerlndex 到 capacity 之间为可写的字节缓冲区；0 到 readerIndex 之间是已经读取过的缓冲区。

Channel 和 Unsafe组件

Channel 是 JDK 的 NIO类库的一个重要组成部分，就是 java.nio.SocketChannel 和 java.nio.ServerSocketChannel，它们用于非阻塞的 IO操作。类似于 NIO 的 Channel，Netty 也提供了自己的 Channel 和其子类实现，用于异步 IO操作和其他相关的操作。

Unsafe 是个内部接口，聚合在 Channel 中协助进行网络读写相关的操作，因为它的设计初衷就是 Channel 的内部辅助类，不应该被 Netty框架的上层使用者调用，所以被命名为 Unsafe。

Channel功能说明

io.netty.channel.Channel 是 Netty网络操作抽象类，它聚合了一组功能，包括但不限于网路的读、写，客户端发起连接，主动关闭连接，链路关闭，获取通信双方的网络地址等。它也包含了 Netty框架相关的一些功能，包括获取该 Chanel 的 EventLoop，获取缓冲分配器 ByteBufAllocator 和 pipeline 等。

Channel工作原理

Channel 是 Netty 抽象出来的网络 I/O 读写相关的接口，为什么不使用 JDK NIO 原生的 Channel 而要另起炉灶呢，主要原因如下。

JDK 的 SocketChannel 和 ServerSocketChannel 没有统一的 Channel接口供业务开发者使用，对于用户而言，没有统一的操作视图，使用起来并不方便。
JDK 的 SocketChannel 和 ServerSocketChannel 的主要职责就是网络I/O操作，由于它们是 SPI类接口，由具体的虚拟机厂家来提供，所以通过继承 SPI功能类来扩展其功能的难度很大；直接实现 ServerSocketChannel 和 SocketChannel 抽象类，其工作量和重新开发一个新的 Channel功能类是差不多的。
Netty 的 Channel 需要能够跟 Netty 的整体架构融合在一起，例如 I/O模型、基于 ChannelPipeline 的定制模型，以及基于元数据描述配置化的 TCP参数等，对于这些功能，JDK 的 SocketChannel 和 ServerSocketChannel 都没有提供，需要重新封装。
自定义的 Channel，功能实现更加灵活。

基于上述 4 个原因，Netty 重新设计了 Channel接口，并且给予了很多不同的实现。它的设计原理比较简单，但是功能却比较繁杂，主要的设计理念如下。

在 Channel 接口层，采用 Facade模式进行统一封装，将网络I/O操作、网络I/O相关联的其他操作封装起来，统一对外提供。
Channel 接口的定义尽量大而全，为 SocketChannel 和 ServerSocketChannel 提供统一的视图，由不同子类实现不同的功能，公共功能在抽象父类中实现，最大程度地实现功能和接口的重用。
具体实现采用聚合而非包含的方式，将相关的功能类聚合在 Channel 中，由 Channel 统一负责分配和调度，功能实现更加灵活。

Unsafe功能说明

Unsafe接口实际上是 Channel接口的辅助接口，它不应该被用户代码直接调用。实际的I/O读写操作都是由Unsafe接口负责完成的。

ChannelPipeline 和 ChannelHandler 组件

Netty 的 ChannelPipeline 和 ChannelHandler 机制类似于 Servlet 和 Filter过滤器，这类拦截器实际上是职责链模式的一种变形，主要是为了方便事件的拦截和用户业务逻辑的定制。

Servlet 和 Filter 是 J2EE Web 应用程序级的 Java 代码组件，它能够以声明的方式插入到 HTTP请求响应的处理过程中，用于拦截请求和响应，以便能够查看、提取或以某种方式操作正在客户端和服务器之间交换的数据。拦截器封装了业务定制逻辑，能够实现对 Web 应用程序的预处理和事后处理。

过滤器提供了一种面向对象的模块化机制，用来将公共任务封装到可插入的组件中。这些组件通过 Web 部署配置文件 ( web.xml ) 进行声明，可以方便地添加和删除过滤器，无须改动任何应用程序代码或 JSP页面，由 Servlet 进行动态调用。通过在请求/响应链中使用过滤器，可以对应用程序的 Servlet 或 JSP页面提供的核心处理进行补充，而不破坏 Servlet 或 JSP页面的功能。由于是纯Java实现，所以 Servlet 过滤器具有跨平台的可重用性，使得它们很容易被部署到任何符合 Servlet规范的 J2EE环境中。

Netty 的 Channel过滤器实现原理与 Servlet Filter 机制一致，它将 Channel 的数据管道抽象为 ChannelPipeline，消息在 ChannelPipeline 中流动和传递。ChannelPipeline 持有 I/O事件拦截器 ChannelHandler 的链表，由 ChannelHandler 对 I/O事件 ( 读/写 ) 进行拦截和处理，可以方便地通过新增和删除 ChannelHandler 来实现不同的业务逻辑定制，不需要对已有的 ChannelHandler 进行修改，能够实现对修改封闭和对扩展的支持。

ChannelPipeline 组件

ChannelPipeline 是 ChannelHandler 的容器，它负责 ChannelHandler 的管理和事件拦截与调度。

下图展示了一个消息被 ChannelPipeline 的 ChannelHandler链拦截和处理的全过程，消息的读取和发送处理全流程描述如下。

底层的 SocketChannel read() 方法读取 ByteBuf，触发 ChannelRead 事件，由 I/O线程 NioEventLoop 调用 ChannelPipeline 的 fireChannelRead(Object msg)方法，将消息（ByteBuf）传输到 ChannelPipeline 中。
消息依次被 Inbound Handler 链拦截和处理，在这个过程中，任何 ChannelHandler 都可以中断当前的流程，结束消息的传递。
调用 ChannelHandlerContext 的 write()方法发送消息，消息从 Outbound Handler 1 开始，沿着拦截器链，最终被添加到消息发送缓冲区（ByteBuf）中等待刷新和发送。

Netty 中的事件分为 inbound事件和 outbound事件。inbound事件通常由 I/O线程触发，例如 TCP链路建立事件、链路关闭事件、读事件、异常通知事件等。Outbound事件通常是由用户主动发起的网络I/O操作，例如用户发起的连接操作、绑定操作、消息发送等操作。

ChannelPipeline 通过 ChannelHandler 接口来实现事件的拦截和处理，由于 ChannelHandler 中的事件种类繁多，不同的 ChannelHandler 可能只需要关心其中的某一个或者几个事件，所以，通常 ChannelHandler 只需要继承 ChannelHandlerAdapter类覆盖自己关心的方法即可。

ChannelHandler 组件

ChannelHandler 类似于 Servlet 的 Filter 过滤器，负责对 I/O事件或者 I/O操作进行拦截和处理，它可以选择性地拦截和处理自已感兴趣的事件，也可以终止事件的传递。基于 ChannelHandler接口，用户可以方便地进行业务逻辑定制，例如打印日志、统一封装异常信息、性能统计和消息编解码等。

EventLoop 和 EventLoopGroup

EventLoop 翻译过来就是 “事件循环” ，可以理解为：循环监听所有 “已建立连接的链路” 的 IO事件，如：SelectionKey.OP_READ / OP_WRITE / OP_CONNECT / OP_ACCEPT。

从本章开始我们将学习 Netty 的线程模型。Netty框架的主要线程就是 I/O线程，线程模型设计的好坏，决定了系统的吞吐量、并发性和安全性等架构质量属性。Netty的线程模型被精心地设计，既提升了框架的并发性能，又能在很大程度避免锁，局部实现了无锁化设计。下面我们来看一下 Netty 的线程模型，同时对它的 NIO线程 NioEventLoop 进行详尽地源码分析，从中学到更多 I/O 相关的多线程设计原理和实现。

Netty 线程模型

当我们讨论 Netty线程模型的时候，一般首先会想到的是经典的 Reactor线程模型，尽管不同的 NIO框架对于 Reactor模式的实现存在差异，但本质上还是遵循了 Reactor 的基础线程模型。下面让我们一起回顾经典的 Reactor线程模型。

Reactor 单线程模型

Reactor单线程模型，是指所有的 I/O操作都在同一个 NIO线程上面完成。NIO线程的职责及模型图如下。

作为 NIO服务端，接收客户端的 TCP连接；
作为 NIO客户端，向服务端发起 TCP连接；
读取通信对端的请求或者应答消息；
向通信对端发送消息请求或者应答消息。

由于 Reactor模式使用的是异步非阻塞I/O，所有的 I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有 I/O相关的操作。从架构层面看，一个 NIO线程确实可以完成其承担的职责。例如，通过 Aceptor类接收客户端的 TCP连接请求消息，当链路建立成功之后，通过 Dispatch 将对应的 ByteBuffer 派发到指定的 Handler 上，进行消息解码。用户线程完成消息编码后通过 NIO线程将消息发送给客户端。在一些小容量应用场景下，可以使用单线程模型。但是这对于高负载、大并发的应用场景却不合适，主要原因如下。
一个 NIO线程同时处理成百上千的链路，性能上无法支撑，即便 NIO线程的 CPU 负荷达到 100%，也无法满足海量消息的编码、解码、读取和发送。
当 NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了 NIO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。
可靠性问题。一旦 NIO线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

为了解决这些问题，演进出了 Reactor多线程模型。下面我们一起看一下 Reactor多线程模型。

Reactor 多线程模型

Rector多线程模型与单线程模型最大的区别就是有一组 NIO线程来处理 I/O操作，它的原理如下图所示。
在这里插入图片描述
Reactor多线程模型的特点如下。

有专门一个 NIO线程 —— Acceptor线程用于监听服务端，接收客户端的 TCP连接请求。
网络 I/O操作 —— 读、写等由一个 NIO线程池负责，线程池可以采用标准的 JDK线程池实现，它包含一个任务队列和 N个可用的线程，由这些 NIO线程负责消息的读取、解码、编码和发送。
一个 NIO线程可以同时处理 N 条链路，但是一个链路只对应一个 NIO线程，防止发生并发操作问题。

在绝大多数场景下，Reactor 多线程模型可以满足性能需求。但是，在个别特殊场景中，一个 NIO线程负责监听和处理所有的客户端连接可能会存在性能问题。例如并发百万的客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。在这类场景下，单独一个 Acceptor线程可能会存在性能不足的问题，为了解决性能问题，产生了第三种 Reactor线程模型 —— 主从Reactor多线程模型。

主从 Reactor 多线程模型

主从Reactor线程模型的特点是，服务端用于接收客户端连接的不再是一个单独的 NIO线程，而是一个独立的 NIO线程池。Acceptor 接收到客户端 TCP连接请求并处理完成后 ( 处理过程可能包含接入认证等 )，将新创建的 SocketChannel 注册到 I/O线程池的某个 I/O线程上，由它负责 SocketChannel 的读写和编解码工作。Acceptor线程池仅仅用于客户端的登录、握手和安全认证，一旦链路建立成功，就将链路注册到后端 Reactor线程池的 I/O线程上，由 I/O线程负责后续的 I/O操作。它的线程模型如下图所示。
在这里插入图片描述
利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。因此，在 Netty 的官方 Demo 中，推荐使用该线程模型。

Netty 的线程模型

Netty 的线程模型并不是一成不变的，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty 可以同时支持 Reactor单线程模型、多线程模型和主从Reactor多线层模型。下面让我们通过其原理图，来快速了解 Netty 的线程模型。
在这里插入图片描述
可以通过下面的 Netty服务端启动代码，来了解它的线程模型。

    EventLoopGroup parentGroup = new NioEventLoopGroup();
    EventLoopGroup childGroup = new NioEventLoopGroup();
    try {
        ServerBootstrap b = new ServerBootstrap();
        b.group(parentGroup, childGroup)
        .channel(NioServerSocketChannel.class)
        .option(ChannelOption.SO_BACKLOG, 1024)
        .childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            public void initChannel(SocketChannel ch) throws Exception {
            	......
            }
        });
		......

服务端启动的时候，创建了两个 NioEventLoopGroup对象，它们实际是两个独立的 Reactor线程池。一个用于接收客户端的 TCP连接，另一个用于处理 I/O相关的读写操作，或者执行系统Task、定时任务Task 等。Netty 用于接收客户端请求的线程池职责如下。

接收客户端 TCP连接，初始化 Channel参数；
将链路状态变更事件通知给 ChannelPipeline。

Netty 处理 I/O操作的 Reactor线程池职责如下。

异步读取通信对端的数据报，发送读事件到 ChannelPipeline；
异步发送消息到通信对端，调用 ChannelPipeline 的消息发送接口；
执行系统调用 Task；
执行定时任务 Task，例如链路空闲状态监测定时任务。

通过调整线程池的线程个数、是否共享线程池等方式，Netty 的 Reactor线程模型可以在单线程、多线程和主从多线程间切换，这种灵活的配置方式可以最大程度地满足不同用户的个性化定制。

为了尽可能地提升性能，Netty 在很多地方进行了无锁化的设计，例如在 I/O 线程内部进行串行操作，避免多线程竞争导致的性能下降问题。表面上看，串行化设计似乎 CPU利用率不高，并发程度不够。但是，通过调整 NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比 “ 一个队列 —— 多个工作线程 ” 的模型性能更优。它的设计原理如下图所示。
在这里插入图片描述
Netty 的 NioEventLoop 读取到消息之后，直接调用 ChannelPipeline 的 fireChannelRead(Object msg)方法。只要用户不主动切换线程，一直都是由 NioEventLoop 调用用户的 Handler，期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。

最佳实践

Netty 的多线程编程最佳实践如下。

创建两个 NioEventLoopGroup，用于逻辑隔离 NIO Acceptor线程池和 NIO I/O操作线程池。
尽量不要在 ChannelHandler 中启动用户线程。
解码要放在 NIO线程调用的解码Handler 中进行，不要切换到用户线程进行消息的解码。
如果业务逻辑操作非常简单，没有复杂的业务逻辑计算，没有可能会导致线程被阻塞的磁盘操作、数据库操作、网路操作等，可以直接在 NIO线程上完成业务逻辑编排，不需要切换到用户线程。
如果业务逻辑处理复杂，不要在 NIO线程上完成，建议将解码后的 POJO消息封装成 Task，派发到业务线程池中由业务线程执行，以保证 NIO线程尽快被释放，处理其他的 I/O操作。

NioEventLoop 源码分析

Netty 的 NioEventLoop 并不是一个纯粹的 I/O线程，它除了负责 I/O 的读写之外，还兼顾处理以下两类任务。

系统Task：通过调用 NioEventLoop 的 execute(Runnable task)方法实现，Netty 有很多系统Task，创建它们的主要原因是，当 I/O线程和用户线程同时操作网络资源时，为了防止并发操作导致的锁竞争，将用户线程的操作封装成 Task 放入消息队列中，由 I/O线程负责执行，这样就实现了局部无锁化。
定时任务：通过调用 NioEventLoop 的 schedule(Runnable command, long delay, TimeUnit unit)方法实现。

话不多说，直接上源码。

public final class NioEventLoop extends SingleThreadEventLoop {

    /**
     * 作为 NIO框架 的 Reactor线程，NioEventLoop 需要处理 网络I/O读写事件，因此它
     * 必须聚合一个多路复用器对象
     */
    private Selector selector;
    private Selector unwrappedSelector;
    private SelectedSelectionKeySet selectedKeys;

    private final SelectorProvider provider;

    /**
     * 初始化 Selector
     */
    private SelectorTuple openSelector() {
        final Selector unwrappedSelector;
        try {
            unwrappedSelector = provider.openSelector();
        } catch (IOException e) {
            throw new ChannelException("failed to open a new selector", e);
        }

        if (DISABLE_KEY_SET_OPTIMIZATION) {
            return new SelectorTuple(unwrappedSelector);
        }

        Object maybeSelectorImplClass = AccessController.doPrivileged(new PrivilegedAction<Object>() {
            @Override
            public Object run() {
                try {
                    return Class.forName(
                            "sun.nio.ch.SelectorImpl",
                            false,
                            PlatformDependent.getSystemClassLoader());
                } catch (Throwable cause) {
                    return cause;
                }
            }
        });

        if (!(maybeSelectorImplClass instanceof Class) ||
            // ensure the current selector implementation is what we can instrument.
            !((Class<?>) maybeSelectorImplClass).isAssignableFrom(unwrappedSelector.getClass())) {
            if (maybeSelectorImplClass instanceof Throwable) {
                Throwable t = (Throwable) maybeSelectorImplClass;
                logger.trace("failed to instrument a special java.util.Set into: {}", unwrappedSelector, t);
            }
            return new SelectorTuple(unwrappedSelector);
        }

        final Class<?> selectorImplClass = (Class<?>) maybeSelectorImplClass;
        final SelectedSelectionKeySet selectedKeySet = new SelectedSelectionKeySet();

        Object maybeException = AccessController.doPrivileged(new PrivilegedAction<Object>() {
            @Override
            public Object run() {
                try {
                    Field selectedKeysField = selectorImplClass.getDeclaredField("selectedKeys");
                    Field publicSelectedKeysField = selectorImplClass.getDeclaredField("publicSelectedKeys");

                    if (PlatformDependent.javaVersion() >= 9 && PlatformDependent.hasUnsafe()) {
                        // Let us try to use sun.misc.Unsafe to replace the SelectionKeySet.
                        // This allows us to also do this in Java9+ without any extra flags.
                        long selectedKeysFieldOffset = PlatformDependent.objectFieldOffset(selectedKeysField);
                        long publicSelectedKeysFieldOffset =
                                PlatformDependent.objectFieldOffset(publicSelectedKeysField);

                        if (selectedKeysFieldOffset != -1 && publicSelectedKeysFieldOffset != -1) {
                            PlatformDependent.putObject(
                                    unwrappedSelector, selectedKeysFieldOffset, selectedKeySet);
                            PlatformDependent.putObject(
                                    unwrappedSelector, publicSelectedKeysFieldOffset, selectedKeySet);
                            return null;
                        }
                        // We could not retrieve the offset, lets try reflection as last-resort.
                    }

                    Throwable cause = ReflectionUtil.trySetAccessible(selectedKeysField, true);
                    if (cause != null) {
                        return cause;
                    }
                    cause = ReflectionUtil.trySetAccessible(publicSelectedKeysField, true);
                    if (cause != null) {
                        return cause;
                    }

                    selectedKeysField.set(unwrappedSelector, selectedKeySet);
                    publicSelectedKeysField.set(unwrappedSelector, selectedKeySet);
                    return null;
                } catch (NoSuchFieldException e) {
                    return e;
                } catch (IllegalAccessException e) {
                    return e;
                }
            }
        });

        if (maybeException instanceof Exception) {
            selectedKeys = null;
            Exception e = (Exception) maybeException;
            logger.trace("failed to instrument a special java.util.Set into: {}", unwrappedSelector, e);
            return new SelectorTuple(unwrappedSelector);
        }
        selectedKeys = selectedKeySet;
        logger.trace("instrumented a special java.util.Set into: {}", unwrappedSelector);
        return new SelectorTuple(unwrappedSelector,
                                 new SelectedSelectionKeySetSelector(unwrappedSelector, selectedKeySet));
    }

    /**
     * 所有的逻辑操作都在for循环体内进行,只有当 NioEventLoop 接收到退出指令的时候，
     * 才退出循环，否则一直执行下去，这也是通用的 NIO线程 实现方式。
     */
    @Override
    protected void run() {
        for (;;) {
            try {
                try {
                    switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {
                    case SelectStrategy.CONTINUE:
                        continue;

                    case SelectStrategy.BUSY_WAIT:

                    case SelectStrategy.SELECT:
                        select(wakenUp.getAndSet(false));
                        if (wakenUp.get()) {
                            selector.wakeup();
                        }
                    default:
                    }
                } catch (IOException e) {
                    rebuildSelector0();
                    handleLoopException(e);
                    continue;
                }

                cancelledKeys = 0;
                needsToSelectAgain = false;
                final int ioRatio = this.ioRatio;
                if (ioRatio == 100) {
                    try {
                        processSelectedKeys();
                    } finally {
                        runAllTasks();
                    }
                } else {
                    final long ioStartTime = System.nanoTime();
                    try {
                        processSelectedKeys();
                    } finally {
                        final long ioTime = System.nanoTime() - ioStartTime;
                        runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
                    }
                }
            } catch (Throwable t) {
                handleLoopException(t);
            }
            try {
                if (isShuttingDown()) {
                    closeAll();
                    if (confirmShutdown()) {
                        return;
                    }
                }
            } catch (Throwable t) {
                handleLoopException(t);
            }
        }
    }
}

Future 和 Promise 组件

从名字可以看出，Future 用于获取异步操作的结果，而 Promise 则比较抽象，无法直接猜测出其功能。

Future 组件

Future 最早来源于 JDK 的 java.util.concurrent.Future，它用于代表异步操作的结果。可以通过 get()方法获取操作结果，如果操作尚未完成，则会同步阻塞当前调用的线程；如果不允许阻塞太长时间或者无限期阻塞，可以通过带超时时间的 get()方法获取结果；如果到达超时时间操作仍然没有完成，则抛出 TimeoutException。