NioEventLoop啟動流程原始碼解析

NioEventLoop的啟動時機是在服務端的NioServerSocketChannel中的ServerSocketChannel初始化完成,且註冊在NioEventLoop後執行的, 下一步就是去繫結埠,但是在繫結埠前,需要完成NioEventLoop的啟動工作, 因為程式執行到這個階段為止,依然只有MainThread一條執行緒,下面就開始閱讀原始碼看NioEventLoop如何開啟新的執行緒自立家門的

總想說 NioEventLoop的整體結構,像極了這個圖

---

該圖為,是我畫的NioEventLoop啟動的流程草圖,很糙,但是不畫它,總覺的少了點啥...

NioEventLoop的繼承體系圖

NioEventLoop的執行緒開啟之路

程式的入口是AbstractBootStrap, 這個抽象的啟動輔助類, 找到它準備繫結埠的doBind0()方法,下面是原始碼:

private static void doBind0(
        final ChannelFuture regFuture, final Channel channel,
        final SocketAddress localAddress, final ChannelPromise promise) {

    // This method is invoked before channelRegistered() is triggered.  Give user handlers a chance to set up
    // the pipeline in its channelRegistered() implementation.
    // todo  此方法在觸發  channelRegistered() 之前呼叫, 給使用者一個機會,在  channelRegistered()  中設定pipeline
    // todo 這是 eventLoop啟動的邏輯 ,  下面的Runable就是一個 task任務, 什麼任務的呢? 繫結埠
    // todo 進入exeute()
    System.out.println("00000");
    channel.eventLoop().execute(new Runnable() {
        @Override
        public void run() {
            if (regFuture.isSuccess()) {
                // todo channel繫結埠並且新增了一個listenner
                channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
            } else {
                promise.setFailure(regFuture.cause());
            }
        }
    });
}

我們關注上面的channel.execute(Runable)方法, 如果我們直接使用滑鼠點選進去,會進入java.util.concurrent包下的Executor介面, 原因是因為,它是NioEventLoop繼承體系的超頂級介面,見上圖, 我們進入它的實現類,SingleThreadEventExcutor, 也就是NioEventLoop的間接父類, 原始碼如下:

 // todo eventLoop事件迴圈裡面的task,會在本類SingleThreadEventExecutor裡面: execute() 執行
    @Override
public void execute(Runnable task) {
    if (task == null) {
        throw new NullPointerException("task");
    }
    // todo 同樣判斷當前執行緒是不是 eventLoop裡面的那條唯一的執行緒, 如果是的話, 就把當前任務放到任務佇列裡面等著當前的執行緒執行
    // todo ,不是的話就開啟新的執行緒去執行這個新的任務
    // todo , eventLoop一生只會繫結一個執行緒,伺服器啟動時只有一條主執行緒,一直都是在做初始化的工作,並沒有任何一次start()
    // todo 所以走的是else, 在else中首先開啟新的執行緒,而後把任務新增進去
    boolean inEventLoop = inEventLoop();
    if (inEventLoop) {
        addTask(task);
    } else {
        // todo 開啟執行緒 , 進入檢視
        startThread();
        // todo 把任務丟進佇列
        addTask(task);
        if (isShutdown() && removeTask(task)) {
            reject();
        }
    }

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

現在執行這些程式碼的執行緒依然是主執行緒,主執行緒手上有繫結埠任務,但是它想把這個任務提交給NioEventLoop去執行,於是它就做出下面的判斷

boolean inEventLoop = inEventLoop();
// 方法實現
@Override
public boolean inEventLoop(Thread thread) {
    return thread == this.thread;
}

但是發現,主執行緒並不是NioEventLoop唯一繫結的那個執行緒, 於是他就準備下面兩件事:

• 開啟啟用當前NioEventLoop中的執行緒
• 把繫結埠的任務新增到任務佇列

開啟新執行緒的邏輯在下面,我刪除了一些收尾,以及判斷的程式碼,保留了主要的邏輯

   private void doStartThread() {
    assert thread == null;
    // todo 斷言執行緒為空, 然後才建立新的執行緒
    executor.execute(new Runnable() { // todo 每次Execute 都是在使用 預設的執行緒工廠,建立一個執行緒並執行 Runable裡面的任務
    @Override
    public void run() {
    // todo 獲取剛才建立出來的執行緒,儲存在NioEventLoop中的 thread 變數裡面, 這裡其實就是在進行那個唯一的繫結
    thread = Thread.currentThread();
    updateLastExecutionTime();
    try {
        // todo 實際啟動執行緒, 到這裡  NioEventLoop 就啟動完成了
        SingleThreadEventExecutor.this.run();
    }
}

主要做了兩件事第一波高潮來了 1. 呼叫了NioEventLoop的執行緒執行器的execute,這個方法的原始碼在下面,可以看到,excute,其實就是在建立執行緒, 執行緒建立完成後,立即把新建立出來的執行緒當作是NioEventLoop相伴終生的執行緒;

public final class ThreadPerTaskExecutor implements Executor {
    private final ThreadFactory threadFactory;

    public ThreadPerTaskExecutor(ThreadFactory threadFactory) {
        if (threadFactory == null) {
            throw new NullPointerException("threadFactory");
        }
        this.threadFactory = threadFactory;
    }

    // todo  必須實現 Executor 裡面唯一的抽象方法, execute , 執行性 任務
    @Override
    public void execute(Runnable command) {
        threadFactory.newThread(command).start();
    }
}

建立/繫結完成了新的執行緒後,第二波高潮來了, SingleThreadEventExecutor.this.run(); 這行程式碼的意思是,呼叫本類的Run()方法,這個Run()方法就是真正在幹活的事件迴圈,但是呢, 在本類中,Run()是一個抽象方法,因此我們要去找他的子類,那麼是誰重寫的這個Run()呢? 就是NioEventLoop, 它根據自己需求,重寫了這個方法

小結: 到現在,NioEventLoop的執行緒已經開啟了,下面的重頭戲就是看他是如何進行事件迴圈的

---

NioEventLoop的事件迴圈run()

我們來到了NioEventLoop的run(), 他是個無限for迴圈, 主要完成了下面三件事

• 輪詢IO事件
• 處理IO事件
• 處理非IO任務

這是NioEventLoop的run()的原始碼,刪除了部分註解和收尾工作,

/**
 * todo select()  檢查是否有IO事件
 * todo ProcessorSelectedKeys()    處理IO事件
 * todo RunAllTask()    處理非同步任務佇列
 */
@Override
protected void run() {
    for (; ; ) {
        try {
            switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {
                case SelectStrategy.CONTINUE:
                    continue;
                case SelectStrategy.SELECT:
                    // todo 輪詢IO事件, 等待事件的發生, 本方法下面的程式碼是處理接受到的感性趣的事件, 進入檢視本方法
                    select(wakenUp.getAndSet(false));
                    if (wakenUp.get()) {
                        selector.wakeup();
                    }
                default:
            }

            cancelledKeys = 0;
            needsToSelectAgain = false;
            final int ioRatio = this.ioRatio;  // todo 預設50
            // todo  如果ioRatio==100 就呼叫第一個     processSelectedKeys();  否則就呼叫第二個
            if (ioRatio == 100) {
                try {
                    // todo 處理 處理髮生的感性趣的事件
                    processSelectedKeys();
                } finally {
                    // Ensure we always run tasks.
                    // todo 用於處理 本 eventLoop外的執行緒 扔到taskQueue中的任務
                    runAllTasks();
                }
            } else {// todo 因為ioRatio預設是50 , 所以來else
                // todo 記錄下開始的時間
                final long ioStartTime = System.nanoTime();
                try {
                    // todo 處理IO事件
                    processSelectedKeys();
                } finally {
                    // Ensure we always run tasks.
                    // todo  根據處理IO事件耗時 ,控制 下面的runAllTasks執行任務不能超過 ioTime 時間
                    final long ioTime = System.nanoTime() - ioStartTime;
                    // todo 這裡面有聚合任務的邏輯
                    runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
                }
            }
        } catch (Throwable t) {
            handleLoopException(t);
        }

    }
}

下面進入它的select(),我們把select()稱作: 基於deadline的任務穿插處理邏輯
下面直接貼出它的原始碼:下面的程式碼中我寫了一些註解了, 主要是分如下幾步走

• 根據當前時間計算出本次for()的最遲截止時間, 也就是他的deadline
• 判斷1 如果超過了 截止時間,selector.selectNow(); 直接退出
• 判斷2 如果任務佇列中出現了新的任務 selector.selectNow(); 直接退出
• 經過了上面12兩次判斷後, netty 進行阻塞式select(time) ,預設是1秒這時可會會出現空輪詢的Bug
• 判斷3 如果經過阻塞式的輪詢之後,出現的感興趣的事件,或者任務佇列又有新任務了,或者定時任務中有新任務了,或者被外部執行緒喚醒了 都直接退出迴圈
• 如果前面都沒出問題,最後檢驗是否出現了JDK空輪詢的BUG

// todo 迴圈接受IO事件
// todo 每次進行 select()  操作時, oldWakenUp被標記為false
private void select(boolean oldWakenUp) throws IOException {
Selector selector = this.selector;
try {
    ///todo ----------------------------------------- 如下部分程式碼, 是 select()的deadLine及任務穿插處理邏輯-----------------------------------------------------
   // todo selectCnt這個變數記錄了 迴圈 select的次數
    int selectCnt = 0;
    // todo 記錄當前時間
    long currentTimeNanos = System.nanoTime();
    // todo 計算出估算的截止時間,  意思是, select()操作不能超過selectDeadLineNanos這個時間, 不讓它一直耗著,外面也可能有任務等著當前執行緒處理
    long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);

        // -------for 迴圈開始  -------
    for (; ; ) {
        // todo 計算超時時間
        long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
        if (timeoutMillis <= 0) {// todo 如果超時了 , 並且selectCnt==0 , 就進行非阻塞的 select() , break, 跳出for迴圈
            if (selectCnt == 0) {
                selector.selectNow();
                selectCnt = 1;
            }
            break;
        }

        // todo  判斷任務佇列中時候還有別的任務, 如果有任務的話, 進入程式碼塊, 非阻塞的select() 並且 break; 跳出迴圈
        //todo  通過cas 把執行緒安全的把 wakenU設定成true表示退出select()方法, 已進入時,我們設定oldWakenUp是false
        if (hasTasks() && wakenUp.compareAndSet(false, true)) {
            selector.selectNow();
            selectCnt = 1;
            break;
        }
        ///todo ----------------------------------------- 如上部分程式碼, 是 select()的deadLine及任務穿插處理邏輯-----------------------------------------------------

        ///todo ----------------------------------------- 如下, 是 阻塞式的select() -----------------------------------------------------

        // todo  上面設定的超時時間沒到,而且任務為空,進行阻塞式的 select() , timeoutMillis 預設1
        // todo netty任務,現在可以放心大膽的 阻塞1秒去輪詢 channel連線上是否發生的 selector感性的事件
        int selectedKeys = selector.select(timeoutMillis);

        // todo 表示當前已經輪詢了SelectCnt次了
        selectCnt++;

        // todo 阻塞完成輪詢後,馬上進一步判斷 只要滿足下面的任意一條. 也將退出無限for迴圈, select()
        // todo  selectedKeys != 0      表示輪詢到了事件
        // todo  oldWakenUp              當前的操作是否需要喚醒
        // todo  wakenUp.get()          可能被外部執行緒喚醒
        // todo  hasTasks()             任務佇列中又有新任務了
        // todo   hasScheduledTasks()   當時定時任務佇列裡面也有任務
        if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks() || hasScheduledTasks()) {
            break;
        }
        ///todo ----------------------------------------- 如上, 是 阻塞式的select() -----------------------------------------------------

        if (Thread.interrupted()) {
            if (logger.isDebugEnabled()) {
                logger.debug("Selector.select() returned prematurely because " +
                        "Thread.currentThread().interrupt() was called. Use " +
                        "NioEventLoop.shutdownGracefully() to shutdown the NioEventLoop.");
            }
            selectCnt = 1;
            break;
        }
      
      
        // todo 每次執行到這裡就說明,已經進行了一次阻塞式操作 ,並且還沒有監聽到任何感興趣的事件,也沒有新的任務新增到佇列,  記錄當前的時間
        long time = System.nanoTime();
        // todo 如果  當前的時間 - 超時時間 >= 開始時間   把 selectCnt設定為1 , 表明已經進行了一次阻塞式操作
        // todo  每次for迴圈都會判斷, 當前時間 currentTimeNanos 不能超過預訂的超時時間 timeoutMillis
        // todo 但是,現在的情況是, 雖然已經進行了一次 時長為timeoutMillis時間的阻塞式select了,
        // todo  然而, 我執行到當前程式碼的 時間 - 開始的時間 >= 超時的時間

        // todo 但是   如果 當前時間- 超時時間< 開始時間, 也就是說,並沒有阻塞select, 而是立即返回了, 就表明這是一次空輪詢
        // todo 而每次輪詢   selectCnt ++;  於是有了下面的判斷,
        if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
            // timeoutMillis elapsed without anything selected.
            selectCnt = 1;
        } else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
                // todo  selectCnt如果大於 512 表示cpu確實在空輪詢, 於是rebuild Selector
                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, selector);
            // todo 它的邏輯建立一個新的selectKey , 把老的Selector上面的key註冊進這個新的selector上面 , 進入檢視
            rebuildSelector();
            selector = this.selector;

            // Select again to populate selectedKeys.
            // todo 解決了Select空輪詢的bug
            selector.selectNow();
            selectCnt = 1;
            break;
        }

        currentTimeNanos = time;
    }

    ////   -----------for 迴圈結束 --------------

    if (selectCnt > MIN_PREMATURE_SELECTOR_RETURNS) {
        if (logger.isDebugEnabled()) {
            logger.debug("Selector.select() returned prematurely {} times in a row for Selector {}.",
                    selectCnt - 1, selector);
        }
    }
} catch (CancelledKeyException e) {
    if (logger.isDebugEnabled()) {
        logger.debug(CancelledKeyException.class.getSimpleName() + " raised by a Selector {} - JDK bug?",
                selector, e);
    }
    // Harmless exception - log anyway
}
}

什麼是Jdk的Selector空輪詢

我們可以看到,上面的run()方法,經過兩次判斷後進入了指定時長的阻塞式輪詢,而我們常說的空輪詢bug,指的就是本來該阻塞住輪詢,但是卻直接返回了, 在這個死迴圈中,它的暢通執行很可能使得CPU的使用率飆升, 於是把這種情況說是jdk的selector的空輪詢的bug

Netty 如何解決了Jdk的Selector空輪詢bug?

一個分支語句 if(){}else{} , 首先他記錄下,現在執行判斷時的時間, 然後用下面的公式判斷

當前的時間t1 - 預訂的deadLine截止時間t2  >= 開始進入for迴圈的時間t3

我們想, 如果說,上面的阻塞式select(t2)沒出現任何問題,那麼 我現在來檢驗是否出現了空輪詢是時間t1 = t2+執行其他程式碼的時間, 如果是這樣, 上面的等式肯定是成立的, 等式成立說沒bug, 順道把selectCnt = 1;

但是如果出現了空輪詢,select(t2) 並沒有阻塞,而是之間返回了, 那麼現在的時間 t1 = 0+執行其他程式碼的時間, 這時的t1相對於上一個沒有bug的大小,明顯少了一個t2, 這時再用t1-t2 都可能是一個負數, 等式不成立,就進入了else的程式碼塊, netty接著判斷,是否是真的在空輪詢, 如果說迴圈的次數達到了512次, netty就確定真的出現了空輪詢, 於是nettyrebuild()Selector ,從新開啟一個Selector, 迴圈老的Selector上面的上面的註冊的時間,重新註冊進新的 Selector上,用這個中替換Selector的方法,解決了空輪詢的bug

---

感性趣的事件,是何時新增到selectedkeys中的?

ok, run()的三部曲第一步輪詢已經完成了, 下一步就是處理輪詢出來的感興趣的IO事件,processSelectedKeys() ,下面我們進入這個方法, 如果這個selectedKeys不為空,就進去processSelectedKeysOptimized();繼續處理IO事件,
比較有趣的是,這個selectedKeys是誰? ,別忘了我們是在NioEventLoop中,是它開啟了Selector,也是他使用反射的手段將Selector,存放感興趣事件的HashSet集合替換成了SelectedSelectionKeySet這個名叫set,實為陣列的資料結構, 當時的情況如下:

• 建立出SelectedSelectionKeySet的例項 selectedKeySet
• 使用反射,將 unwrappedSelector 中的 selectedKeysField欄位,替換成 selectedKeySet
• 最後一步, 也很重要 selectedKeys = selectedKeySet;

看到第三步沒? 也就是說,我們現在再想獲取裝有感興趣Key的 HashSet集合,已經不可能了,取而代之的是更優秀的selectedKeySet,也就是下面我們使用的selectedKeys ,於是我們想處理感性趣的事件,直接從selectedKeys中取, Selector輪詢到感興趣的事件,也會直接往selectedKeys中放

private void processSelectedKeys() {
    // todo  selectedKeys 就是經過優化後的keys(底層是陣列) 
    if (selectedKeys != null) {
        processSelectedKeysOptimized();
    } else {
        processSelectedKeysPlain(selector.selectedKeys());
    }
}

下面接著跟進processSelectedKeysOptimized();,關於這個方法的有趣的地方,我寫在這段程式碼的下面

private void processSelectedKeysOptimized() {
for (int i = 0; i < selectedKeys.size; ++i) {
    final SelectionKey k = selectedKeys.keys[i];
    // null out entry in the array to allow to have it GC'ed once the Channel close
    // todo 陣列輸出空項, 從而允許在channel 關閉時對其進行垃圾回收
    // See https://github.com/netty/netty/issues/2363
    // todo 陣列中當前迴圈對應的keys質空, 這種感興趣的事件只處理一次就行
    selectedKeys.keys[i] = null;

    // todo 獲取出 attachment,預設情況下就是註冊進Selector時,傳入的第三個引數  this===>   NioServerSocketChannel
    // todo 一個Selector中可能被繫結上了成千上萬個Channel,  通過K+attachment 的手段, 精確的取出發生指定事件的channel, 進而獲取channel中的unsafe類進行下一步處理
    final Object a = k.attachment();
    // todo

    if (a instanceof AbstractNioChannel) {
        // todo 進入這個方法, 傳進入 感興趣的key + NioSocketChannel
        processSelectedKey(k, (AbstractNioChannel) a);
    } else {
        @SuppressWarnings("unchecked")
        NioTask<SelectableChannel> task = (NioTask<SelectableChannel>) a;
        processSelectedKey(k, task);
    }

    if (needsToSelectAgain) {
        // null out entries in the array to allow to have it GC'ed once the Channel close
        // See https://github.com/netty/netty/issues/2363
        selectedKeys.reset(i + 1);

        selectAgain();
        i = -1;
    }
}
}

NioEventLoop是如何在千百條channel中,精確獲取出現指定感興趣事件的channel的?

上面這個方法,就是在真真正正的處理IO事件, 看看這段程式碼, 我們發現了這樣一行程式碼

  final Object a = k.attachment();

並且,判斷出Key的型別後,執行處理邏輯的程式碼中的入參都是一樣的processSelectedKey(a,k) , 這是在幹什麼呢?

其實,我們知道,每個NioEventLoop開始幹活後,會有很多客戶端的連線channel前來和它建立連線,一個事件迴圈同時為多條channel服務,而且一條channel的整個生命週期都只和一個NioEventLoop關聯

現在好了,事件迴圈的選擇器輪詢出了諸多的channel中有channel出現了感興趣的事件,下一步處理這個事件的前提得知道,究竟是哪個channel?

使用的attachment特性,早在Channel註冊進Selector時,進存放進去了,下面是Netty中,Channel註冊進Selector的原始碼

  @Override
    protected void doRegister() throws Exception {
boolean selected = false;
for (;;) {
    try {
        // todo  javaChannel() -- 返回SelectableChanel 可選擇的Channel,換句話說,可以和Selector搭配使用,他是channel體系的頂級抽象類, 實際的型別是 ServerSocketChannel
        // todo  eventLoop().unwrappedSelector(), -- >  獲取選擇器, 現在在AbstractNioChannel中 獲取到的eventLoop是BossGroup裡面的
        // todo  到目前看, 他是把ServerSocketChannel(系統建立的) 註冊進了 EventLoop的選擇器
     
        // todo 到目前為止, 雖然註冊上了,但是它不關心任何事件
        selectionKey = javaChannel().register(eventLoop().unwrappedSelector(), 0, this);
        return;
    } catch (CancelledKeyException e) {

這裡的 最後一個引數是 this是當前的channel , 意思是把當前的Channel當成是一個 attachment(附件) 繫結到selector上 作用如下:

• 當channel在這裡註冊進 selector中返回一個selectionKey, 這個key告訴selector 這個channel是自己的
• 當selector輪詢到 有channel出現了自己的感興趣的事件時, 需要從成百上千的channel精確的匹配出 出現Io事件的channel,於是seleor就在這裡提前把channel存放入 attachment中, 後來使用
• 最後一個 this 引數, 如果是服務啟動時, 他就是NioServerSocketChannel 如果是客戶端他就是 NioSocketChannel

ok, 現在就捋清楚了,挖坑,填坑的過程; 下面進入processSelectedKey(SelectionKey k, AbstractNioChannel ch)執行IO任務, 原始碼如下: 我們可以看到,具體的處理IO的任務都是用Channel的內部類unSafe()完成的, 到這裡就不往下跟進了, 後續寫新部落格連載

private void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {
        // todo 這個unsafe 也是可channel 也是和Channel進行唯一繫結的物件
        final AbstractNioChannel.NioUnsafe unsafe = ch.unsafe();
        if (!k.isValid()) {   // todo 確保Key的合法
            final EventLoop eventLoop;
            try {
                eventLoop = ch.eventLoop();
            } catch (Throwable ignored) {
                // If the channel implementation throws an exception because there is no event loop, we ignore this
                // because we are only trying to determine if ch is registered to this event loop and thus has authority
                // to close ch.
                return;
            }
            // Only close ch if ch is still registered to this EventLoop. ch could have deregistered from the event loop
            // and thus the SelectionKey could be cancelled as part of the deregistration process, but the channel is
            // still healthy and should not be closed.
            // See https://github.com/netty/netty/issues/5125
            if (eventLoop != this || eventLoop == null) { // todo 確保多執行緒下的安全性
                return;
            }
            // close the channel if the key is not valid anymore
            unsafe.close(unsafe.voidPromise());
            return;
        }
        // todo NioServerSocketChannel和selectKey都合法的話, 就進入下面的 處理階段
        try {
            // todo 獲取SelectedKey 的 關心的選項
            int readyOps = k.readyOps();
            // We first need to call finishConnect() before try to trigger a read(...) or write(...) as otherwise
            // the NIO JDK channel implementation may throw a NotYetConnectedException.
            // todo 在read()   write()之前我們需要呼叫 finishConnect()  方法, 否則  NIO JDK丟擲異常
            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( );

                unsafe.finishConnect();
            }

            // Process OP_WRITE first as we may be able to write some queued buffers and so free memory.
            if ((readyOps & SelectionKey.OP_WRITE) != 0) {
                // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to  write
                ch.unsafe().forceFlush();
            }

            // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead
            // to a spin loop
            // todo 同樣是檢查 readOps是否為零, 來檢查是否出現了  jdk  空輪詢的bug
            if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
                unsafe.read();
            }
        } catch (CancelledKeyException ignored) {
            unsafe.close(unsafe.voidPromise());
        }
    }

---

處理非IO任務

上面的處理IO事件結束後,第三波高潮就來了,處理任務佇列中的任務, runAllTask(timeOutMinils), 他也是有生命時長限制的 deadline, 它主要完成了如下的幾步:

• 聚合任務, 把到期的定時任務轉移到普通任務佇列
• 迴圈從普通佇列獲取任務
  • 執行任務
  • 每執行完64個任務,判斷是否到期了
• 收尾工作

原始碼如下:

protected boolean runAllTasks(long timeoutNanos) {
    // todo 聚合任務, 會把定時任務放入普通的任務佇列中 進入檢視
    fetchFromScheduledTaskQueue();

    // todo 從普通的佇列中拿出一個任務
    Runnable task = pollTask();
    if (task == null) {
        afterRunningAllTasks();
        return false;
    }

    // todo 計算截止時間, 表示任務的執行,最好別超過這個時間
    final long deadline = ScheduledFutureTask.nanoTime() + timeoutNanos;
    long runTasks = 0;
    long lastExecutionTime;

    // todo for迴圈執行任務
    for (;;) {
        // todo 執行任務, 方法裡呼叫 task.run();
        safeExecute(task);

        runTasks ++;

        // Check timeout every 64 tasks because nanoTime() is relatively expensive.
        // XXX: Hard-coded value - will make it configurable if it is really a problem.
        // todo 因為 nanoTime();的執行也是個相對耗時的操作,因此沒執行完64個任務後,檢查有沒有超時
        if ((runTasks & 0x3F) == 0) {
            lastExecutionTime = ScheduledFutureTask.nanoTime();
            if (lastExecutionTime >= deadline) {
                break;
            }
        }
        // todo 拿新的任務
        task = pollTask();
        if (task == null) {
            lastExecutionTime = ScheduledFutureTask.nanoTime();
            break;
        }
    }
    // todo 每個任務執行結束都有個收尾的構造
    afterRunningAllTasks();
    this.lastExecutionTime = lastExecutionTime;
    return true;
}

NioEventLoop如何聚合任務?

聚合任務就是把已經到執行時間的任務從定時任務佇列中全部取出 ,放入普通任務佇列然後執行, 我們進入上的第一個方法fetchFromScheduledTaskQueue,原始碼如下,

private boolean fetchFromScheduledTaskQueue() {
    // todo 拉取第一個聚合任務
    long nanoTime = AbstractScheduledEventExecutor.nanoTime();
    // todo 從任務丟列中取出 截止時間是 nanoTime的定時任務 ,
    // todo 往定時佇列中新增 ScheduledFutureTask任務, 排序的基準是 ScheduledFutureTask 的compare方法,按照時間,從小到大
    // todo 於是當我們發現佇列中的第一個任務,也就是截止時間最近的任務的截止時間比我們的
    Runnable scheduledTask  = pollScheduledTask(nanoTime);

    while (scheduledTask != null) {
        // todo scheduledTask != null表示定時任務該被執行了, 於是將定時任務新增到 普通任務佇列
        if (!taskQueue.offer(scheduledTask)) {
            // No space left in the task queue add it back to the scheduledTaskQueue so we pick it up again.

            // todo 如果新增失敗了, 把這個任務從新放入到定時任務佇列中, 再嘗試新增
            scheduledTaskQueue().add((ScheduledFutureTask<?>) scheduledTask);
            return false;
        }
        // todo 迴圈,嘗試拉取定時任務 , 迴圈結束後,所有的任務全部會被新增到 task裡面
        scheduledTask  = pollScheduledTask(nanoTime);
    }
    return true;
}

根據指定的截止時間,從定時任務佇列中取出任務,定時任務佇列中任務按照時間排序,時間越短的,排在前面, 時間相同,按照新增的順序排序, 現在的任務就是檢查定時任務佇列中任務,嘗試把裡面的任務挨個取出來,於是netty使用這個方法Runnable scheduledTask = pollScheduledTask(nanoTime); 然後馬上在while(){}迴圈中判斷是否存在, 這個方法實現原始碼如下, 不難看出,他是在根據時間判斷

  /**
 * Return the {@link Runnable} which is ready to be executed with the given {@code nanoTime}.
 * You should use {@link #nanoTime()} to retrieve the the correct {@code nanoTime}.
 *  todo  根據給定的納秒值,返回 Runable定時任務 , 並且,每次使用都要衝洗使用是nanoTime() 來矯正時間
 */
protected final Runnable pollScheduledTask(long nanoTime) {
    assert inEventLoop();

    Queue<ScheduledFutureTask<?>> scheduledTaskQueue = this.scheduledTaskQueue;
    ScheduledFutureTask<?> scheduledTask = scheduledTaskQueue == null ? null : scheduledTaskQueue.peek();
    if (scheduledTask == null) {
        return null;
    }
    // todo 如果定時任務的截止時間<= 我們穿進來的時間, 就把他返回
    if (scheduledTask.deadlineNanos() <= nanoTime) {
        scheduledTaskQueue.remove();
        return scheduledTask;
    }
    // todo 否則返回kong,表示當前所有的定時任務都沒到期, 沒有可以執行的
    return null;
}

經過迴圈之後,到期的任務,全被新增到 taskQueue裡面了,下面就是執行TaskQueue裡面的任務

任務佇列中的任務是怎麼執行的?

safeExecute(task); 方法,執行任務佇列中的任務
原始碼如下: 實際上就行執行了 task這個Runable的Run方法

/**
 * Try to execute the given {@link Runnable} and just log if it throws a {@link Throwable}.
 */
protected static void safeExecute(Runnable task) {
    try {
        task.run();
    } catch (Throwable t) {
        logger.warn("A task raised an exception. Task: {}", task, t);
    }
}

總結一下: 到現在為止,EventLoop已經啟動了, 一說到NioEventLoop總是想起上圖, 現在他可以接受新的連線接入,輪詢,處理任務...