select，poll，epoll对比及epoll空轮询

目录

一、select，poll，epoll对比

1.select

2.poll

3.epoll

4.总结

二、epoll空轮询bug及处理

1.Selector BUG出现的原因

2.Netty的解决办法

---

一、select，poll，epoll对比

1.select

支持一个进程所能打开的最大连接数

单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是3232，同理64位机器上FD_SETSIZE为3264），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测

试。

FD剧增后带来的IO效率问题

因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。

消息传递方式

内核需要将消息传递到用户空间，都需要内核拷贝动作

2.poll

支持一个进程所能打开的最大连接数

poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的

FD剧增后带来的IO效率问题

因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。

消息传递方式

内核需要将消息传递到用户空间，都需要内核拷贝动作

 

3.epoll

支持一个进程所能打开的最大连接数

虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接

FD剧增后带来的IO效率问题

因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。

消息传递方式

epoll通过内核和用户空间共享一块内存来实现的。

4.总结

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善 

3、select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写

事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。  

二、epoll空轮询bug及处理

1.Selector BUG出现的原因

若Selector的轮询结果为空，也没有wakeup或新消息处理，则发生空轮询，CPU使用率100%

这个bug的描述内容为，在NIO的selector中，即使是关注的select轮询事件的key为0的话，NIO照样不断的从select本应该阻塞的

情况中wake up出来，也就是下图中的红色阻塞的部分：

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

因为selector的select方法，返回numKeys是0，所以下面本应该对key值进行遍历的事件处理根本执行不了，又回到最上面的while(true)循环，循环往复，不断的轮询，直到linux系统出现100%的CPU情况，其它执行任务干不了活，最终导致程序崩溃。

从这个bug上来看，这个绝对是JDK中的问题，select方法就应该是阻塞的，没有key事件过来，那么就不应该返回，和应用程序的写法没有任何的关系

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

年才最终修复的原因，最终影响力太广。

2.Netty的解决办法

1) 根据该BUG的特征，首先侦测该BUG是否发生

   侦测方法：对Selector的select操作周期进行统计，每完成一次空的select操作进行一次计数；

                  若在某个周期内连续发生N次空轮询，则触发了epoll死循环bug， netty默认是512次

2) 将问题Selector上注册的Channel转移到新建的Selector上；

3) 老的问题Selector关闭，使用新建的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