Netty之大名鼎鼎的EventLoop

最新推荐文章于 2023-04-15 09:30:00 发布

随风去。

最新推荐文章于 2023-04-15 09:30:00 发布

阅读量1k

点赞数

分类专栏： Netty

本文链接：https://blog.csdn.net/weixin_41358004/article/details/103676454

版权

Netty 专栏收录该内容

17 篇文章 0 订阅

订阅专栏

EventLoopGroup 与Reactor:

　　前面的章节中我们已经知道了，一个Netty 程序启动时，至少要指定一个EventLoopGroup(如果使用到的是NIO，通常是指NioEventLoopGroup)，那么，这个NioEventLoopGroup 在Netty 中到底扮演着什么角色呢? 我们知道，Netty是Reactor 模型的一个实现，我们就从Reactor 的线程模型开始。

浅谈Reactor 线程模型:

　　Reactor 的线程模型有三种:单线程模型、多线程模型、主从多线程模型。首先来看一下单线程模型，如下图所示：

　　所谓单线程, 即Acceptor 处理和andler 处理都在同一个线程中处理。这个模型的坏处显而易见：当其中某个Handler阻塞时, 会导致其他所有的Client 的Handler 都得不到执行，并且更严重的是，Handler 的阻塞也会导致整个服务不能接收新的Client 请求(因为Acceptor 也被阻塞了)。因为有这么多的缺陷，因此单线程Reactor 模型应用场景比较少。

　　那么，什么是多线程模型呢? Reactor 的多线程模型与单线程模型的区别就是Acceptor 是一个单独的线程处理，并且有一组特定的NIO 线程来负责各个客户端连接的IO 操作。Reactor 多线程模型如下图所示：

Reactor 多线程模型有如下特点:

有专门一个线程，即Acceptor 线程用于监听客户端的TCP 连接请求。
客户端连接的IO 操作都由一个特定的NIO 线程池负责.每个客户端连接都与一个特定的NIO 线程绑定,因此在这个客户端连接中的所有IO 操作都是在同一个线程中完成的。
客户端连接有很多，但是NIO 线程数是比较少的，因此一个NIO 线程可以同时绑定到多个客户端连接中。

　　接下来我们再来看一下Reactor 的主从多线程模型。一般情况下, Reactor 的多线程模式已经可以很好的工作了，但是我们想象一个这样的场景：如果我们的服务器需要同时处理大量的客户端连接请求或我们需要在客户端连接时，进行一些权限的校验，那么单线程的Acceptor 很有可能就处理不过来，造成了大量的客户端不能连接到服务器。Reactor 的主从多线程模型就是在这样的情况下提出来的，它的特点是：服务器端接收客户端的连接请求不再是一个线程，而是由一个独立的线程池组成。其线程模型如下图所示：

　　可以看到，Reactor 的主从多线程模型和Reactor 多线程模型很类似，只不过Reactor 的主从多线程模型的Acceptor使用了线程池来处理大量的客户端请求。

EventLoopGroup 与Reactor 关联:

　　我们介绍了三种Reactor 的线程模型, 那么它们和NioEventLoopGroup 又有什么关系呢? 其实，不同的设置NioEventLoopGroup 的方式就对应了不同的Reactor 的线程模型。

1、单线程模型，来看下面的应用代码：

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
ServerBootstrap server = new ServerBootstrap();
server.group(bossGroup);

　　注意，我们实例化了一个NioEventLoopGroup，然后接着我们调用server.group(bossGroup)设置了服务器端的EventLoopGroup。有人可能会有疑惑；我记得在启动服务器端的Netty 程序时, 需要设置bossGroup 和workerGroup，为何这里只设置一个bossGroup？其实原因很简单，ServerBootstrap 重写了group 方法：

public ServerBootstrap group(EventLoopGroup group) {
return group(group, group);
}

　　因此当传入一个group 时，那么bossGroup 和workerGroup 就是同一个NioEventLoopGroup 了。这时，因为bossGroup 和workerGroup 就是同一个NioEventLoopGroup，并且这个NioEventLoopGroup 线程池数量只设置了1个线程，也就是说Netty 中的Acceptor 和后续的所有客户端连接的IO 操作都是在一个线程中处理的。那么对应到Reactor 的线程模型中，我们这样设置NioEventLoopGroup 时，就相当于Reactor 的单线程模型。

2、多线程模型，再来看下面的应用代码：

EventLoopGroup bossGroup = new NioEventLoopGroup(128);
ServerBootstrap server = new ServerBootstrap();
server.group(bossGroup);

　　从上面代码中可以看出，我们只需要将bossGroup 的参数就设置为大于1 的数，其实就是Reactor 多线程模型。

3、主从线程模型，到这里相信大家都已经想到了, 实现主从线程模型的代码如下:

EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup);

　　bossGroup 为主线程，而workerGroup 中的线程是CPU 核心数乘以2，因此对应的到Reactor 线程模型中，我们知道, 这样设置的NioEventLoopGroup 其实就是Reactor 主从多线程模型。

EventLoopGroup 的实例化:

　　首先，我们先纵览一下EventLoopGroup 的类结构图，如下图所示：

　　在前面的章节中我们已经简单地介绍了一下NioEventLoopGroup 初始化的基本过程，这里我们再回顾一下时序图：

基本步骤如下：

EventLoopGroup(其实是MultithreadEventExecutorGroup)内部维护一个类为EventExecutor children 数组，其大小是nThreads，这样就初始化了一个线程池。
如果我们在实例化NioEventLoopGroup 时，如果指定线程池大小，则nThreads 就是指定的值，否则是CPU核数* 2。
在MultithreadEventExecutorGroup 中会调用newChild()抽象方法来初始化children 数组.
抽象方法newChild()实际是在NioEventLoopGroup 中实现的，由它返回一个NioEventLoop 实例。
初始化NioEventLoop 主要属性：
1. provider：在NioEventLoopGroup 构造器中通过SelectorProvider 的provider()方法获取SelectorProvider。
2. selector：在NioEventLoop 构造器中调用selector = provider.openSelector()方法获取Selector 对象。

任务执行者EventLoop:

　　NioEventLoop 继承自SingleThreadEventLoop，而SingleThreadEventLoop 又继承自SingleThreadEventExecutor。而SingleThreadEventExecutor 是Netty 中对本地线程的抽象，它内部有一个Thread thread 属性，存储了一个本地Java线程。因此我们可以简单地认为，一个NioEventLoop 其实就是和一个特定的线程绑定，并且在其生命周期内，绑定的线程都不会再改变。

　　NioEventLoop 的类层次结构图还是有些复杂的，不过我们只需要关注几个重要点即可。首先来看NioEventLoop 的继承链：NioEventLoop->SingleThreadEventLoop->SingleThreadEventExecutor->AbstractScheduledEventExecutor。在AbstractScheduledEventExecutor 中, Netty 实现了NioEventLoop 的schedule 功能，即我们可以通过调用一个NioEventLoop 实例的schedule 方法来运行一些定时任务。而在SingleThreadEventLoop 中，又实现了任务队列的功能，通过它，我们可以调用一个NioEventLoop 实例的execute()方法来向任务队列中添加一个task,并由NioEventLoop进行调度执行。通常来说，NioEventLoop 负责执行两个任务：第一个任务是作为IO 线程，执行与Channel 相关的IO 操作，包括调用Selector 等待就绪的IO 事件、读写数据与数据的处理等；而第二个任务是作为任务队列，执行taskQueue 中的任务，例如用户调用eventLoop.schedule 提交的定时任务也是这个线程执行的。

NioEventLoop 的实例化过程:

　　之前的章节我们分析过，SingleThreadEventExecutor 启动时会调用doStartThread()方法，然后调用executor.execute()方法，将当前线程赋值给thread。在这个线程中所做的事情主要就是调用SingleThreadEventExecutor.this.run()方法，而因为NioEventLoop 实现了这个方法，因此根据多态性，其实调用的是NioEventLoop.run()方法。

EventLoop 与Channel 的关联:

　　在Netty 中, 每个Channel 都有且仅有一个EventLoop 与之关联, 它们的关联过程如下(红色部分)：

　　从上图中我们可以看到，当调用AbstractChannel$AbstractUnsafe.register()方法后，就完成了Channel 和EventLoop的关联。在AbstractChannel$AbstractUnsafe.register() 方法中, 会将一个EventLoop 赋值给AbstractChannel 内部的eventLoop 字段，这句代码就是完成EventLoop 与Channel 的关联过程。

public final void register(EventLoop eventLoop, final ChannelPromise promise) {
            AbstractChannel.this.eventLoop = eventLoop;
            register0(promise);

}

EventLoop 的启动：

　　在前面我们已经知道了，NioEventLoop 本身就是一个SingleThreadEventExecutor，因此NioEventLoop 的启动，其实就是NioEventLoop 所绑定的本地Java 线程的启动。按照这个思路，我们只需要找到在哪里调用了SingleThreadEventExecutor 中thread 字段的start()方法就可以知道是在哪里启动的这个线程了。从前面章节的分析中，其实我们已经清楚： thread.start() 被封装到了SingleThreadEventExecutor.startThread()方法中，来看代码：

private void startThread() {
        if (STATE_UPDATER.get(this) == 1 && STATE_UPDATER.compareAndSet(this, 1, 2)) {
            this.doStartThread();
        }
}

　　STATE_UPDATER 是SingleThreadEventExecutor 内部维护的一个属性，它的作用是标识当前的thread 的状态。在初始的时候，STATE_UPDATER == ST_NOT_STARTED，因此第一次调用startThread()方法时，就会进入到if 语句内，进而调用到thread.start()方法。我们发现，startThread 是在SingleThreadEventExecutor 的execute()方法中调用的。既然如此，那现在我们的工作就变为了寻找在哪里第一次调用了SingleThreadEventExecutor 的execute()方法。

　　如果细心的小伙伴可能已想到了, 我们在前面章节中，我们有提到到在注册channel 的过程中，会在AbstractChannel$AbstractUnsafe 的register()中调用eventLoop.execute()方法，在EventLoop 中进行Channel 注册代码的执行，AbstractChannel$AbstractUnsafe 的register()部分代码如下：

public final void register(EventLoop eventLoop, final ChannelPromise promise) {
            AbstractChannel.this.eventLoop = eventLoop;

            if (eventLoop.inEventLoop()) {
                register0(promise);
            } else {
                try {
                    eventLoop.execute(new Runnable() {
                        @Override
                        public void run() {
                            register0(promise);
                        }
                    });
            }
}

　　很显然，一路从Bootstrap 的bind()方法跟踪到AbstractChannel$AbstractUnsafe 的register()方法，整个代码都是在主线程中运行的，因此上面的eventLoop.inEventLoop()返回为false，于是进入到else 分支，在这个分支中调用了eventLoop.execute()方法，而NioEventLoop 没有实现execute()方法，因此调用的是SingleThreadEventExecutor 的execute()方法：

public void execute(Runnable task) {
        if (task == null) {
            throw new NullPointerException("task");
        } else {
            boolean inEventLoop = this.inEventLoop();
            if (inEventLoop) {
                this.addTask(task);
            } else {
                this.startThread();
                this.addTask(task);
                if (this.isShutdown() && this.removeTask(task)) {
                    reject();
                }
            }

            if (!this.addTaskWakesUp && this.wakesUpForTask(task)) {
                this.wakeup(inEventLoop);
            }

        }
    }

　　我们已经分析过了， inEventLoop == false ，因此执行到else 分支，在这里就调用startThread() 方法来启动SingleThreadEventExecutor 内部关联的Java 本地线程了。

　　总结一句话：当EventLoop 的execute()第一次被调用时，就会触发startThread()方法的调用，进而导致EventLoop所对应的Java 本地线程启动。