Epoll空轮询bug

bug表现

epoll bug

• 正常状况下，selector.select()操做是阻塞的，只有被监听的fd有读写操做时，才被唤醒
• 可是，在这个bug中，没有任何fd有读写请求，可是select()操做依旧被唤醒
• 很显然，这种状况下，selectedKeys()返回的是个空数组
• 而后按照逻辑执行到while(true)处，循环执行，致使死循环。

bug缘由

JDK bug列表中有两个相关的bug报告：

1. JDK-6670302 : (se) NIO selector wakes up with 0 selected keys infinitely
2. JDK-6403933 : (se) Selector doesn't block on Selector.select(timeout) (lnx)

JDK-6403933的bug说出了实质的缘由：

This is an issue with poll (and epoll) on Linux. If a file descriptor for a connected socket is polled with a request event mask of 0, and if the connection is abruptly terminated (RST) then the poll wakes up with the POLLHUP (and maybe POLLERR) bit set in the returned event set. The implication of this behaviour is that Selector will wakeup and as the interest set for the SocketChannel is 0 it means there aren't any selected events and the select method returns 0.

具体解释为：在部分Linux的2.6的kernel中，poll和epoll对于忽然中断的链接socket会对返回的eventSet事件集合置为POLLHUP，也多是POLLERR，eventSet事件集合发生了变化，这就可能致使Selector会被唤醒。

这是与操做系统机制有关系的，JDK虽然仅仅是一个兼容各个操做系统平台的软件，但很遗憾在JDK5和JDK6最初的版本中（严格意义上来将，JDK部分版本都是），这个问题并无解决，而将这个帽子抛给了操做系统方，这也就是这个bug最终一直到2013年才最终修复的缘由，最终影响力太广。

解决办法

不完善的解决办法

grizzly的commiteer们最早进行修改的，而且经过众多的测试说明这种修改方式大大下降了JDK NIO的问题。

if (SelectionKey != null)  {  // the key you registered on the temporary selector
   SelectionKey.cancel();   // cancel the SelectionKey that was registered with the temporary selector
   // flush the cancelled key
   temporarySelector.selectNow();
}

可是，这种修改仍然不是可靠的，一共有两点：

1. 多个线程中的SelectionKey的key的cancel，极可能和下面的Selector.selectNow同时并发，若是是致使key的cancel后运行极可能没有效果
2. 与其说第一点使得NIO空转出现的概率大大下降，通过Jetty服务器的测试报告发现，这种重复利用Selector并清空SelectionKey的改法极可能没有任何的效果，

完善的解决办法

最终的终极办法是建立一个新的Selector：

Trash wasted Selector, creates a new one.

各应用具体解决方法

Jetty

Jetty首先定义两了-D参数：

• JVMBUG_THRESHHOLD

org.mortbay.io.nio.JVMBUG_THRESHHOLD, defaults to 512 and is the number of zero select returns that must be exceeded in a period.

• threshhold

org.mortbay.io.nio.MONITOR_PERIOD defaults to 1000 and is the period over which the threshhold applies.

第一个参数是select返回值为0的计数，第二个是多长时间，总体意思就是控制在多长时间内，若是Selector.select不断返回0，说明进入了JVM的bug的模式。

作法是：

• 记录select()返回为0的次数(记作jvmBug次数)
• 在MONITOR_PERIOD时间范围内，若是jvmBug次数超过JVMBUG_THRESHHOLD，则新建立一个selector

Jetty解决空轮询bug

Netty

思路和Jetty的处理方式几乎是同样的，就是netty讲重建Selector的过程抽取成了一个方法。

long currentTimeNanos = System.nanoTime();
for (;;) {
    // 1.定时任务截止事时间快到了，中断本次轮询
    ...
    // 2.轮询过程当中发现有任务加入，中断本次轮询
    ...
    // 3.阻塞式select操做
    selector.select(timeoutMillis);
    // 4.解决jdk的nio bug
    long time = System.nanoTime();
    if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
        selectCnt = 1;
    } else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
            selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {

        rebuildSelector();
        selector = this.selector;
        selector.selectNow();
        selectCnt = 1;
        break;
    }
    currentTimeNanos = time; 
    ...
 }

netty 会在每次进行 selector.select(timeoutMillis) 以前记录一下开始时间currentTimeNanos，在select以后记录一下结束时间，判断select操做是否至少持续了timeoutMillis秒（这里将time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos改为time - currentTimeNanos >= TimeUnit.MILLISECONDS.toNanos(timeoutMillis)或许更好理解一些）, 若是持续的时间大于等于timeoutMillis，说明就是一次有效的轮询，重置selectCnt标志，不然，代表该阻塞方法并无阻塞这么长时间，可能触发了jdk的空轮询bug，当空轮询的次数超过一个阀值的时候，默认是512，就开始重建selector