JDK Epoll空轮询bug

最新推荐文章于 2025-09-25 22:08:33 发布

转载最新推荐文章于 2025-09-25 22:08:33 发布 · 1k 阅读

3 ·

CC 4.0 BY-SA版权

原文链接：https://www.jianshu.com/p/3ec120ca46b2

Java IO 专栏收录该内容

19 篇文章

订阅专栏

本文探讨了epoll机制下JDK NIO出现的一个常见Bug，即Selector.select()在无事件发生时异常唤醒的问题。分析了此Bug的原因及两种解决方案：不完善的临时修复方法与重建Selector的完整解决方案，并介绍了Jetty与Netty的具体实践。

前面讲到了epoll的一些机制，与select和poll等传统古老的IO多路复用机制的一些区别，这些区别实质可以总结为一句话，就是epoll将重要的基于事件的fd集合放在了内核中来完成，因为内核是高效的，所以很多关于fd事件监听集合的操作也是高效的，不方便的就是，因为在内核中，所以我们需要通过系统调用来调用关于fd操作集合，而不是直接自己攒一个。如果在linux中，epoll在JDK6中还需要配置，在后续的版本中为JDK的NIO提供了默认的实现，但是epoll在JDK中的实现却是漏洞百出的，bug非常的多，比较容易复现并且被众多人诟病的就是epoll轮询的处理方法。

1. Bug说明

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

2. Bug分析

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

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部分版本都是），这个问题并没有解决，而将这个帽子抛给了操作系统方。

3. 解决办法

3.1 不完善的解决办法

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();
}

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

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

3.2 完善的解决办法

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

Trash wasted Selector, creates a new one.

3.3 各应用具体解决方法

3.3.1 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

3.3.2 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。