Netty 多线程模型

    时间回到十几年前，那时主流的CPU都还是单核（除了商用高性能的小机），CPU的核心频率是机器最重要的指标之一

在Java领域当时比较流行的是单线程编程，对于CPU密集型的应用程序而言， 频繁的通过多线程进行协作和抢占时间片反而会降低性能

  随着硬件性能的提升，CPU的核数越来越越多，很多服务器标配已经达到32或64核

  通过多线程并发编程，可以充分利用多核CPU的处理能力，提升系统的处理效率和并发性能

从2005年开始，随着多核处理器的逐步普及，java的多线程并发编程也逐渐流行起来，当时商用主流的JDK版本是1.4，用户可以通过 new Thread() 的方式创建新的线程

由于JDK1.4并没有提供类似线程池这样的线程管理容器，多线程之间的同步、协作、创建和销毁等工作都需要用户自己实现。由于 创建和销毁线程是个相对比较重量级的操作，因此，这种原始的多线程编程效率和性能都不高

  为了提升Java多线程编程的效率和性能，降低用户开发难度。JDK1.5推出了 java.util.concurrent 并发编程包

  在并发编程类库中，提供了 线程池、线程安全容器、原子类等新的类库，极大的提升了Java多线程编程的效率，降低了开发难度

从JDK1.5开始， 基于线程池的并发编程已经成为Java多核编程的主流

Reactor 单线程 模型， 所有的IO操作 都在 同一个NIO线程 上面完成，NIO线程的职责如下：

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

Reactor单线程模型示意图如下所示：

由于Reactor模式使用的是 异步非阻塞IO ，所有的IO操作都不会导致阻塞，理论上一个线程可以独立处理所有IO相关的操作。从架构层面看，一个NIO线程确实可以完成其承担的职责。例如：

• 通过 Acceptor 类： 接收 客户端的TCP连接请求 消息
• 链路建立成功之后
• 通过 Dispatch ： 对应的ByteBuffer 派发 到指定的 Handler 上进行 消息解码
• 用户线程 可以把 消息编码 通过 NIO线程 将消息 发送给客户端

对于一些 小容量应用场景 ，可以使用单线程模型

  对于高负载、大并发的应用场景却不合适，主要原因如下：

  一个NIO线程同时处理成百上千的链路，性能上无法支撑
  即便NIO线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送

  当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时
  超时之后往往会进行重发，这更加重了NIO线程的负载
  最终会导致大量消息积压和处理超时，成为系统的性能瓶颈

  一旦NIO线程意外跑飞，或者进入死循环
  会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

  为了解决这些问题，演进出了 Reactor多线程模型 

Rector 多线程 模型与单线程模型最大的区别就是有 一组NIO线程 处理IO操作 ，它的原理图如下：

Reactor多线程模型的特点：

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

在 绝大多数场景 下，Reactor多线程模型都可以满足性能需求

  在极个别特殊场景中， 一个NIO线程负责监听和处理所有的客户端连接可能会存在性能问题

  例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能
  在这类场景下，单独一个Acceptor线程可能会存在性能不足问题

  为了解决性能问题，产生了第三种Reactor线程模型 主从Reactor多线程模型 

主从Reactor线程模型 的特点是：

• 服务端用于 接收客户端连接 的不再是个 1个单独的NIO线程 ，而是一个 独立的NIO线程池
• Acceptor 接收 到 客户端TCP连接请求 处理完成 后（可能包含接入 认证 等）
  • 将 新创建 的 SocketChannel 注册 到 IO线程池 的 某个IO线程 上
    • 由它负责 SocketChannel 的 读写 和 编解码 工作

Acceptor线程池仅仅只用于 客户端的登陆 、 握手和安全认证

一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作

它的线程模型如下图所示：

  利用主从NIO线程模型，可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题

它的工作流程总结如下：

1. 从主线程池中随机选择一个Reactor线程作为Acceptor线程，用于绑定监听端口，接收客户端连接
2. Acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作
3. 业务层的链路正式建立，将 SocketChannel 从 主线程池的Reactor线程 的 多路复用器 上摘除， 重新注册 到 Sub线程池的线程 上，用于处理I/O的读写操作

第一步，从用户线程发起创建服务端操作，代码如下：

通常情况下，服务端的创建是在用户进程启动的时候进行，因此一般由Main函数或者启动类负责创建， 服务端的创建由业务线程负责完成

在创建服务端的时候实例化了2个EventLoopGroup：

1个EventLoopGroup实际就是一个EventLoop线程组，负责管理EventLoop的申请和释放*

• EventLoopGroup管理的线程数：可以通过构造函数设置，如果没有设置，默认取 -Dio.netty.eventLoopThreads ，如果该系统参数也没有指定，则为可用的CPU内核数 * 2
• bossGroup线程组:：实际就是Acceptor线程池，负责处理客户端的TCP连接请求，如果系统只有一个服务端端口需要监听，则建议bossGroup线程组线程数设置为1
• workerGroup：是真正负责I/O读写操作的线程组，通过ServerBootstrap的group方法进行设置，用于后续的Channel绑定

第二步，Acceptor线程绑定监听端口，启动NIO服务端

从bossGroup中选择一个Acceptor线程监听服务端，相关代码如下：

其中group()返回的就是bossGroup，next方法用于从线程组中获取可用线程来选择Acceptor线程，代码如下：

服务端Channel创建完成之后，将其注册到多路复用器Selector上，用于接收客户端的TCP连接，核心代码如下：

如果监听到客户端连接，则创建客户端SocketChannel连接，重新注册到workerGroup的IO线程上

首先看Acceptor如何处理客户端的接入：

调用unsafe的read（）方法，对于NioServerSocketChannel，它调用了NioMessageUnsafe的read()方法，代码如下：

最终它会调用NioServerSocketChannel的doReadMessages方法，代码如下：

其中childEventLoopGroup就是之前的workerGroup, 从中选择一个I/O线程负责网络消息的读写

第四步，选择IO线程之后，将SocketChannel注册到多路复用器上，监听READ操作：

处理网络的I/O读写事件，核心代码如下：

第一步，由用户线程发起客户端连接，示例代码如下：

相比于服务端，客户端只需要创建一个EventLoopGroup，因为它不需要独立的线程去监听客户端连接，也没必要通过一个单独的客户端线程去连接服务端。Netty是 异步事件驱动的NIO框架，它的连接和所有IO操作都是异步的，因此不需要创建单独的连接线程 。相关代码如下：

当前的group()就是之前传入的EventLoopGroup，从中获取可用的IO线程EventLoop，然后作为参数设置到新创建的NioSocketChannel中

第二步，发起连接操作，判断连接结果，代码如下：

@Override
protected boolean doConnect(SocketAddress remoteAddress, SocketAddress localAddress) throws Exception {
    if (localAddress != null) {
        javaChannel().socket().bind(localAddress);
    }

    boolean success = false;
    try {
        boolean connected = javaChannel().connect(remoteAddress);
        if (!connected) {
            selectionKey().interestOps(SelectionKey.OP_CONNECT);
        }
        success = true;
        return connected;
    } finally {
        if (!success) {
            doClose();
        }
    }
}

判断连接结果：

• 如果没有连接成功：则监听连接网络操作位SelectionKey.OP_CONNECT
• 如果连接成功：则调用pipeline().fireChannelActive()将监听位修改为READ

第三步，由NioEventLoop的多路复用器轮询连接操作结果，代码如下：

if ((readyOps & SelectionKey.OP_CONNECT) != 0) {
    // remove OP_CONNECT as otherwise Selector.select(..) will always return without blocking
    // See https://github.com/netty/netty/issues/924
    int ops = k.interestOps();
    ops &= ~SelectionKey.OP_CONNECT;
    k.interestOps(ops);

    unsafe.finishConnect();
}

判断连接结果：

public final void finishConnect() {
    // Note this method is invoked by the event loop only if the connection attempt was
    // neither cancelled nor timed out.

    assert eventLoop().inEventLoop();

    try {
        boolean wasActive = isActive();
        doFinishConnect();
        fulfillConnectPromise(connectPromise, wasActive);

如果或连接成功，重新设置监听位为READ：

@Override
protected void doBeginRead() throws Exception {
    // Channel.read() or ChannelHandlerContext.read() was called
    if (inputShutdown) {
        return;
    }

    final SelectionKey selectionKey = this.selectionKey;
    if (!selectionKey.isValid()) {
        return;
    }

    readPending = true;

    final int interestOps = selectionKey.interestOps();
    if ((interestOps & readInterestOp) == 0) {
        selectionKey.interestOps(interestOps | readInterestOp);
    }
}

第四步，由NioEventLoop线程负责I/O读写，同服务端

客户端线程模型如下：

1. 由用户线程负责初始化客户端资源，发起连接操作
2. 如果连接成功，将SocketChannel注册到IO线程组的NioEventLoop线程中，监听读操作位
3. 如果没有立即连接成功，将SocketChannel注册到IO线程组的NioEventLoop线程中，监听连接操作位
4. 连接成功之后，修改监听位为READ，但是不需要切换线程

NioEventLoop是Netty的Reactor线程，它的职责如下：

• 服务端Acceptor线程：负责处理客户端的请求接入
• 客户端Connecor线程：负责注册监听连接操作位，用于判断异步连接结果
• IO线程：监听网络读操作位，负责从SocketChannel中读取报文
• IO线程：负责向SocketChannel写入报文发送给对方，如果发生写半包，会自动注册监听写事件，用于后续继续发送半包数据，直到数据全部发送完成
• 定时任务线程：执行定时任务，例如链路空闲检测和发送心跳消息等
• 线程执行器：执行普通的任务线程(Runnable)

在服务端和客户端线程模型章节我们已经详细介绍了NioEventLoop如何处理网络IO事件，下面简单看下它是如何处理定时任务和执行普通的Runnable的

当系统在运行过程中，如果频繁的进行线程上下文切换，会带来额外的性能损耗。多线程并发执行某个业务流程，业务开发者还需要时刻对线程安全保持警惕，哪些数据可能会被并发修改，如何保护？这不仅降低了开发效率，也会带来额外的性能损耗

在Netty中，有很多功能依赖定时任务，比较典型的有两种：

1. 客户端连接超时控制
2. 链路空闲检测

一种比较常用的设计理念是在NioEventLoop中聚合JDK的定时任务线程池ScheduledExecutorService，通过它来执行定时任务。这样做单纯从性能角度看不是最优，原因有如下三点：

• 在IO线程中聚合了一个独立的定时任务线程池，这样在处理过程中会存在线程上下文切换问题，这就打破了Netty的串行化设计理念
• 存在多线程并发操作问题，因为定时任务Task和IO线程NioEventLoop可能同时访问并修改同一份数据
• JDK的ScheduledExecutorService从性能角度看，存在性能优化空间

最早面临上述问题的是操作系统和协议栈，例如TCP协议栈，其可靠传输依赖超时重传机制，因此每个通过TCP传输的 packet 都需要一个 timer来调度 timeout 事件

这类超时可能是海量的，如果为每个超时都创建一个定时器，从性能和资源消耗角度看都是不合理的

Netty是个异步高性能的NIO框架，它并不是个业务运行容器，因此它 不需要也不应该提供业务容器和业务线程 。合理的设计模式是Netty 只负责提供和管理NIO线程 ，其它的业务层线程模型由用户自己集成，Netty不应该提供此类功能，只要将分层划分清楚，就会更有利于用户集成和扩展

令人遗憾的是在Netty 3系列版本中，Netty提供了类似Mina异步Filter的ExecutionHandler，它聚合了JDK的线程池java.util.concurrent.Executor，用户异步执行后续的Handler

ExecutionHandler是为了解决部分用户Handler可能存在执行时间不确定而导致IO线程被意外阻塞或者挂住，从需求合理性角度分析这类需求本身是合理的，但是Netty提供该功能却并不合适。原因总结如下：

1. 它打破了Netty坚持的串行化设计理念，在消息的接收和处理过程中发生了线程切换并引入新的线程池，打破了自身架构坚守的设计原则，实际是一种架构妥协
2. 潜在的线程并发安全问题，如果异步Handler也操作它前面的用户Handler，而用户Handler又没有进行线程安全保护，这就会导致隐蔽和致命的线程安全问题
3. 用户开发的复杂性，引入ExecutionHandler，打破了原来的ChannelPipeline串行执行模式，用户需要理解Netty底层的实现细节，关心线程安全等问题，这会导致得不偿失

鉴于上述原因，Netty的后续版本彻底删除了ExecutionHandler，而且也没有提供类似的相关功能类，把精力聚焦在Netty的IO线程NioEventLoop上，这无疑是一种巨大的进步，Netty重新开始聚焦在IO线程本身，而不是提供用户相关的业务线程模型

如果业务非常简单，执行时间非常短，不需要与外部网元交互、访问数据库和磁盘，不需要等待其它资源，则建议 直接在业务ChannelHandler 中执行，不需要再启业务的线程或者线程池。避免线程上下文切换，也不存在线程并发问题

对于此类业务，不建议直接在业务ChannelHandler中启动线程或者线程池处理，建议 将不同的业务统一封装成Task，统一投递到后端的业务线程池中进行处理

过多的业务ChannelHandler会带来开发效率和可维护性问题，不要把Netty当作业务容器，对于大多数复杂的业务产品，仍然需要集成或者开发自己的业务容器，做好和Netty的架构分层

对于ChannelHandler，IO线程和业务线程都可能会操作，因为业务通常是多线程模型，这样就会存在多线程操作ChannelHandler。为了尽量避免多线程并发问题，建议按照Netty自身的做法，通过将 操作封装成独立的Task由NioEventLoop统一执行 ，而不是业务线程直接操作，相关代码如下所示：

如果你确认并发访问的数据或者并发操作是安全的，则无需多此一举，这个需要根据具体的业务场景进行判断，灵活处理