netty源码分析之-EventLoop与线程模型（1）

最新推荐文章于 2022-09-06 23:36:20 发布

BigMan-Hui

最新推荐文章于 2022-09-06 23:36:20 发布

阅读量569

点赞数

分类专栏： netty 文章标签： netty 源码 thread

本文链接：https://blog.csdn.net/u011262847/article/details/78107144

版权

netty 专栏收录该内容

11 篇文章 1 订阅

订阅专栏

线程模型确定来代码的执行方式，我们总是必须规避并发执行可能会带来的副作用，所以理解netty所采用的并发模型的影响很重要。netty使用了被称为事件循环的EventLoop来运行任务来处理在连接的生命周期内发生的事件

线程模型

对于EventLoop在事件循环中执行任务可以理解为：

while (!terminated) {
    List<Runnable> readyEvents = blockUntilEventsReady();
    for (Runnable ev: readyEvents) {
        ev.run(); 
    }
}

类的层次图：
这里写图片描述

互相之间关系描述：

对于java.util.concurrent.Executor：

void execute(Runnable command);

从方法签名上就能看出这个是为了支持异步模式的。command表示一个命令。当前线程就是命令者角色，Executor内部的去运行Runnable的线程就是执行者。这里没有提供明确的地方供命令者去取得命令的执行结果。

ExecutorService 继承了Executor 接口，增加了对自身生命周期管理的方法，同时提供了一个Future给命令者去获取命令的执行结果。

ScheduledExecutorService 继承了ExecutorService接口，增加了对定时任务的支持。

EventExecutorGroup 继承了ScheduledExecutorService接口，对原来的ExecutorService的关闭接口提供了增强，提供了优雅的关闭接口。从接口名称上可以看出它是对多个EventExecutor的集合，提供了对多个EventExecutor的迭代访问接口。

EventExecutor 继承EventExecutorGroup，可以看作A是B中的一员，但是A也能迭代访问B中的其他成员。这个继承关系支持了迭代访问这个行为。自然的提供了一个parent接口，来获取所属的EventExecutorGroup 。

netty中线程相关的组件扩展了jdk中相应的实现以更加适合来处理netty中的场景。一个 EventLoop 将由一个永远都不会改变的 Thread 驱动，同时任务 (Runnable 或者 Callable)可以直接提交给 EventLoop 实现，以立即执行或者调度执行。根据配置和可用核心的不同，可能会创建多个 EventLoop 实例用以优化资源的使用，并且单个EventLoop 可能会被指派用于服务多个 Channel。

在netty4中，所有的I/O操作和事件都由已经被分配给了EventLoop的那个Thread来处理（不是来触发，写操作可以从外部的任意线程触发），消除了在多个 ChannelHandler 中进行同步的需要(除了任何可能需要在多个 Channel 中共享的)

可以总结如下：

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

Netty线程模型的卓越性能取决于对于当前执行的Thread的身份的确定，如果当前调用线程正式支撑EventLoop的线程，那么所提交的代码将会被（直接）执行。否则EventLoop将调度该任务以便稍后执行，并将它放入到内部队列中，每个EventLoop都有它自己的任务队列，当对应的EventLoop下次处理它的事件时就会执行队列中的那些任务或事件。这也说明了任何的Thread是如何与Channel直接交互而无需在ChannelHandler中进行额外同步的。因此，永远不要将一个长时运行的任务放入到执行队列中，因为它将阻塞需要在同一线程上执行的任何其他任务，可以通过一个专门的EventExecutor（业务线程池）来处理长时的操作

这里的业务线程池有两种方式能够实现：
第一种是在ChannelHandler的的回调方法中，直接使用线程池，将需要执行的业务任务提交到线程池中。
第二种是借助于Netty提供的向ChannelPipeline添加ChannelHandler时调用的类似于addLast方法来传递EventExecutor
默认情况下，调用pipeline.addLast(new MyServerHandler())，ChannelHandler中的回调方法都是由I/O线程所执行；如果调用ChannelPipeline addLast(EventExecutorGroup group, ChannelHandler… handlers)，那么ChannelHandler中的回调方法就可以由参数中的group线程组来执行

这里写图片描述

异步传输
异步传输使用来少量的EventLoop（以及和它们相关联的Thread），一个Thread可以被多个Channel所共享。在创建EventLoopGroup时就直接分配了EventLoop以确保在需要时它们是可用的，EventLoopGroup负责为每个新创建的Channel分配一个EventLoop，一旦一个Channel被分配给来EventLoop，它将在它的整个生命周期中都使用这个EventLoop，正因为如此它可以使我们从ChannelHandler实现中的线程安全和同步问题中解脱出来。
阻塞传输
对于像OIO（旧的阻塞I/O）这样的其他网络模型，Netty会对每一个Channel都分配一个EventLoop，如同之前一样，确保来每个Channel的I/O事件都将只会被一个Thread处理，这一巧妙的一致性设计对Netty可靠性和易用性做出了巨大贡献

源码分析

引导一个客户端只需要一个 EventLoopGroup，但是一个 ServerBootstrap 则需要两个。因为服务器需要两组不同的 Channel。第一组将只包含一个 ServerChannel，代表服务器自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含所有已创建的用来处理传入客户端连接(对于每个服务器已经接受的连接都有一个)的 Channel。

这里写图片描述

对于服务端常见的启动两个EventLoopGroup的代码：

EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();

bossGroup的作用是接受客户端的连接，连接的数据到来之后，bossGroup不会作任何处理，而是交给workerGroup来完成处理逻辑。NioEventLoopGroup称为异步事件循环组，底层实际上就是死循环，不停的去侦测底层输入输出的事件。可以传入第一个参数表示线程的数量。

EventLoopGroup接口中重要的方法：

    EventLoop next();  1

    ChannelFuture register(Channel channel);  2

    ChannelFuture register(ChannelPromise promise);  3

返回下一个EventLoop供使用
注册一个channel(连接)到EventLoop，并返回一个异步ChannelFuture，当channel注册完成之后ChannelFuture将会被通知。也就是调用这个方法会立即返回，但是可以通过返回的ChannelFuture来异步获取相应的结果数据
传入的ChannelPromise本身就继承了ChannelFuture，因此本身就是一个异步的对象，并且会持有一个Channel的引用，也就是可以通过调用本身的异步方法来获取注册完成之后的数据

如果使用多线程来处理，线程数量的默认创建逻辑如下：

private static final int DEFAULT_EVENT_LOOP_THREADS;

    static {
        DEFAULT_EVENT_LOOP_THREADS = Math.max(1, SystemPropertyUtil.getInt(
                "io.netty.eventLoopThreads", NettyRuntime.availableProcessors() * 2));

        if (logger.isDebugEnabled()) {
            logger.debug("-Dio.netty.eventLoopThreads: {}", DEFAULT_EVENT_LOOP_THREADS);
        }
    }

该方法会调用系统运行时的方法，将操作系统的核心数（超核心技术会*2），然后乘以2作为默认的线程数。

对于线程资源的初始化会通过一个线程工厂来创建线程，但是不会设计到线程启动的代码，只会当有任务提交到来的时候才会启动初始化过的线程：

executor = new ThreadPerTaskExecutor(newDefaultThreadFactory());

SingleThreadEventExecutor

SingleThreadEventExecutor抽象类的定义如下，SingleThreadEventLoop和NioEventLoop一些重要的类都继承了该类：

public abstract class SingleThreadEventExecutor extends AbstractScheduledEventExecutor implements OrderedEventExecutor {}

对于核心方法execute：

@Override
    public void execute(Runnable task) {
        if (task == null) {
            throw new NullPointerException("task");
        }

        boolean inEventLoop = inEventLoop();
        if (inEventLoop) {
            addTask(task);
        } else {
            startThread();
            addTask(task);
            if (isShutdown() && removeTask(task)) {
                reject();
            }
        }

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

如果当前执行所提交的任务线程是EventLoop中的线程则直接添加到队列中去执行，否则尝试启动EventLoop中的线程然后再添加到队列中去执行，具体实现如下：

private void doStartThread() {
        assert thread == null;
        executor.execute(new Runnable() {
            @Override
            public void run() {
                thread = Thread.currentThread();
                if (interrupted) {
                    thread.interrupt();
                }

                boolean success = false;
                updateLastExecutionTime();
                try {
                    //启动线程
                    SingleThreadEventExecutor.this.run();
                    success = true;
                } 
    ...

对于netty线程的执行，所有I/O操作以及所触发的事件操作都是由对应的EventLoop中的线程来执行，会在源码中多处看到以下类似代码片段，来判断是否当前线程是EventLoop中的：

...
        if (eventLoop.inEventLoop()) {
                register0(promise);
            } else {
                try {
                    eventLoop.execute(new Runnable() {
                        @Override
                        public void run() {
                            register0(promise);
                        }
                    });
                } catch (Throwable t) {
                    logger.warn(
                            "Force-closing a channel whose registration task was not accepted by an event loop: {}",
                            AbstractChannel.this, t);
                    closeForcibly();
                    closeFuture.setClosed();
                    safeSetFailure(promise, t);
                }
            }
    ...