Netty源码分析之eventLoop和eventLoopGroup

转：https://blog.csdn.net/lz710117239/article/details/77414726

Reactor单线程模型

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

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

图片.png

由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作。从架构层面上看，一个NIO线程确实可以完成其承担的职责。例如，通过Acceptor类接收客户端的TCP连接请求信息，当链路建立成功之后，通过Dispatch将对应的ByteBuffer派发到指定的Handler上，进行消息解码。用户线程消息编码后通过NIO线程将消息发送给客户端。

在一些小容量的应用场景下，可以使用单线程模型。但是这对于高负载,大并发的应用场景却不合适，主要原因如下。

1.一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的编码，解码，读取和发送。
2.当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加NIO线程的负载，最终会导致大量消息挤压和处理超时，成为系统的性能瓶颈。
3.可靠性问题：一旦NIO线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

Reactor多线程模型

Reactor多线程模型与单线程模型最大的却别就是有一组NIO线程来处理I/O操作，它的原理如图所示：

图片.png

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

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

主从Reactor多线程模型

主从Reactor线程模型的特点是：服务端用于接收客户端链接的不在是一个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP链接请求并处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到I/O线程池（sub reacotr线程池）的某个I/O线程上，由它负责SocketChannel的读写和编码工作。Acceptor线程池仅仅用于客户端登录，握手，和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的I/O线程上，有I/O线程负责后续的I/O操作。

图片.png

利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。因此，在Netty的官方Demo中，推荐使用该线程模型。

Netty的线程模型

Netty的线程模型并不是一成不变的，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty可以同时支持Reactor单线程模型，多线程模型和主从Reactor多线程模型。如下图：

图片.png

通过服务端启动代码来了解它的线程模型：

//配置服务端的NIO线程组
        EventLoopGroup bossGroup = new NioEventLoopGroup();
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try{
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class).option(ChannelOption.SO_BACKLOG, 1024)
                    .childHandler(new ChildChannelHandler());
            //绑定端口，同步等待成功
            ChannelFuture f = b.bind(port).sync();
            //等待服务端监听端口关闭
            f.channel().closeFuture().sync();

        }finally {
            //优雅退出，释放线程池资源
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }

服务端启动的时候，创建了两个NioEventLoopGroup，它们实际是两个独立的Reactor线程池。一个用于接收客户端的TCP连接，另一个用于处理I/O相关的读写操作，或者执行系统Task，定时任务Task等。
Netty用于接收客户端请求的线程池职责如下。
（1）接收客户端TCP连接欸，初始化Channel参数；
（2）将链路状态变更事件通知给ChannelPipeline。
Netty处理I/O操作的Reactor线程池职责如下。
（1）异步读取通信对端的数据报，发送读事件到ChannelPipeline；
（2）异步发送消息到通信对端，调用ChannelPipeline的消息发送接口；
（3）执行系统调用Task；
（4）执行定时任务Task，例如链路空闲状态检测定时任务。
通过调整线程池的线程个数，是否共享线程池等方式，Netty的Reactor线程模型可以在单线程，多线程和主从多线程间切换，这种灵活的配置方式可以最大程度地满足不同用户的个性化定制。

为了尽可能地提升性能，Netty在很多地方进行了无锁化的设计，例如在I/O线程内部进行穿行操作，避免多线程竞争导致的性能下降问题。表面上看，串行化似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同hi启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列——多个工作线程的模型性能更好。

它的设计原理如下如所示：

图片.png

Netty的NioEventLoop读取到消息之后，直接调用ChannelPipeline的fireChannelRead（Object msg）。只要用户不主动切换线程，一直都是由NioEventLoop调用用户的handler，期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。

NioEventLoop源码分析

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）方法实现。
正是因为NioEventLoop具备多种职责，所以它的实现比较特殊，它并不是简单的Runnable，我们来看下它们的继承关系。如下：

图片.png

它实现了EventLoop接口、EventExecutorGroup接口和ScheduledExecutorService接口，正是因为这种设计，导致NioEventLoop和其父类功能实现非常复杂。下面我们重点分析下它的源码实现：

NioEventLoop

作为NIO框架的Reactor线程，NioEventLoop需要处理网络I/O读写事件，因此它必须聚合一个多路复用器对象，看下它的selector定义：

Selector selector;
private SelectedSelectionKeySet selectedKeys;
private final SelectorProvider provider;

直接调用Selector.open()就能创建并打开一个新的Selector。
然后通过反射对selectedKeys进行优化：

try {
            SelectedSelectionKeySet selectedKeySet = new SelectedSelectionKeySet();

            Class selectorImplClass =
                    Class.forName("sun.nio.ch.SelectorImpl", false, ClassLoader.getSystemClassLoader());

            // Ensure the current selector implementation is what we can instrument.
            if (!selectorImplClass.isAssignableFrom(selector.getClass())) {
                return selector;
            }

            Field selectedKeysField = selectorImplClass.getDeclaredField("selectedKeys");
            Field publicSelectedKeysField = selectorImplClass.getDeclaredField("publicSelectedKeys");

            selectedKeysField.setAccessible(true);
            publicSelectedKeysField.setAccessible(true);

            selectedKeysField.set(selector, selectedKeySet);
            publicSelectedKeysField.set(selector, selectedKeySet);

            selectedKeys = selectedKeySet;
            logger.trace("Instrumented an optimized java.util.Set into: {}", selector);

上面代码，如果开启了selectedKeys优化功能，通过反射的方法从Selector实例中获取selectedKeys和publicSelectedKeys将上述两个成员变量设置为可写，通过反射的方式使用Netty构造的selectedKeys包装类selectedKeySet将原JDK的selectedKeys替换掉。默认为开启优化功能。
下面看下run（）方法的实现：

for (;;) {
            oldWakenUp = wakenUp.getAndSet(false);
            try {
                if (hasTasks()) {
                    selectNow();
                } else {
                    select();

Selector的selectNow（）方法会立即触发Selector的选择操作，如果有准备就绪的Channel，则返回就绪的Channel集合。选择完成后在此判断用户是否调用了Selector的wakeup方法，如果调用，执行selector.wakeup()操作。下面我们返回到run()方法，继续分析代码。如果消息队列中没有消息需要处理，则执行select()方法，有Selector多路复用器轮询，看是否有准备就绪的channel。它的实现如下：
取当前系统的纳秒时间，调用delayNanos（）方法计算获得NioEventLoop中定时任务的触发时间。

private void select() throws IOException {
        Selector selector = this.selector;
        try {
            int selectCnt = 0;
            long currentTimeNanos = System.nanoTime();
            long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
            for (;;) {
                long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
                if (timeoutMillis <= 0) {
                    if (selectCnt == 0) {
                        selector.selectNow();
                        selectCnt = 1;
                    }
                    break;
                }

                int selectedKeys = selector.select(timeoutMillis);
                selectCnt ++;

                if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks()) {
                    // Selected something,
                    // waken up by user, or
                    // the task queue has a pending task.
                    break;
                }

                if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
                        selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
                    // The selector returned prematurely many times in a row.
                    // Rebuild the selector to work around the problem.
                    logger.warn(
                            "Selector.select() returned prematurely {} times in a row; rebuilding selector.",
                            selectCnt);

                    rebuildSelector();
                    selector = this.selector;

                    // Select again to populate selectedKeys.
                    selector.selectNow();
                    selectCnt = 1;
                    break;
                }

计算下一个将要触发的定时任务的剩余超时时间，将它转换为毫秒，为超时时间增加0.5毫秒的调整值。对剩余的超时时间进行判断，如果需要立即执行或者已经超时，则调用selector.selectNow()进行轮询操作，将selectCnt设置为1，并退出当前循环。
将定时任务剩余的超时时间作为参数进行select操作，没完成一次select操作，对select计数器selectCnt加1.
Select操作完成之后，需要对结果进行判断，如果存在下列任意一种情况，则退出当前循环。
1.有Channel处于就绪状态，selectedKeys不为0，说明有读写事件需要处理。
2.oldWakenUp为true；
3.系统或者用户调用了wakeup操作，唤醒当前的多路复用器；
4.消息队列中有新的任务需要处理。
如果本次Selector的轮询结果为空，也没有wakeup操作或者是新的消息需要处理，则说明是个空轮询，有可能触发了JDK的epoll bug，它会导致Selector的空轮询，使I/O线程一致处于100%状态。这个问题一直到JDK1.8才得到解决。
解决方式就是上面代码最下面的那层if语句。
（1）对Selector的select周期进行统计；
（2）每完成一次select操作进行一次计数；
（3）当select的操作达到一定次数后，rebuildSelector()重新轮询。

 newSelector = openSelector();
        } catch (Exception e) {
            logger.warn("Failed to create a new Selector.", e);
            return;
        }

        // Register all channels to the new Selector.
        int nChannels = 0;
        for (;;) {
            try {
                for (SelectionKey key: oldSelector.keys()) {
                    Object a = key.attachment();
                    try {
                        if (key.channel().keyFor(newSelector) != null) {
                            continue;
                        }

                        int interestOps = key.interestOps();
                        key.cancel();
                        key.channel().register(newSelector, interestOps, a);
                        nChannels ++;
                    } catch (Exception e) {
                        logger.warn("Failed to re-register a Channel to the new Selector.", e);
                        if (a instanceof AbstractNioChannel) {
                            AbstractNioChannel ch = (AbstractNioChannel) a;
                            ch.unsafe().close(ch.unsafe().voidPromise());
                        } else {
                            @SuppressWarnings("unchecked")
                            NioTask task = (NioTask) a;
                            invokeChannelUnregistered(task, key, e);
                        }
                    }
                }
            } catch (ConcurrentModificationException e) {
                // Probably due to concurrent modification of the key set.
                continue;
            }

            break;
        }

        selector = newSelector;

通过销毁旧的、有问题的多路复用器，使用新建的Selector就可以解决空轮询Selector导致的I/O线程CPU占用100%的问题。
如果轮询到了处于就绪状态的SocketChannel，则需要处理网络I/O事件，相关代码如下：

if (selectedKeys != null) {
                    processSelectedKeysOptimized(selectedKeys.flip());
                } else {
                    processSelectedKeysPlain(selector.selectedKeys());
                }

由于默认开启了selectedKeys的优化功能，所以会进入processSelectedKeysOptimized分支执行。进入该方法，如果有需要处理的channel则进入processSelectedKey方法中，处理I/O事件，其代码如下：

final NioUnsafe unsafe = ch.unsafe();
        if (!k.isValid()) {
            // close the channel if the key is not valid anymore
            unsafe.close(unsafe.voidPromise());
            return;
        }

首先从NioServerSocketChannel或者NioSocketChannel中获取其内部类Unsafe，判断当前选择键是否可用，如果不可用，调用Unsafe的close()方法，释放连接资源。
如果选择键可用，则继续对网络操作位进行判断，代码如下：

int readyOps = k.readyOps();
            // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
            // to a spin loop
            if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
                unsafe.read();
                if (!ch.isOpen()) {
                    // Connection already closed - no need to handle write.
                    return;
                }
            }

如果是读或者连接操作，则调用Unsafe的read方法。此处Unsafe的实现是个多态，对于NioServerSocketChannel，它的读操作就是接收客户端的TCP连接，相关代码如下：

protected int doReadMessages(List