Netty是如何解决JDK中的Selector的bug的？

Selector BUG: JDK NIO的BUG,

例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%,
官方声称在JDK 1.6版本的update18修复了该问题，但是直到JDK1.7版本该问题仍旧存在，只不过该BUG发生
概率降低了一些而已，它并没有被根本解决，甚至JDK1.8的131版本中仍然存在

• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933
• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719
• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302
• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6481709
  简单来说，JDK认为Linux的epoll告诉我事件来了，但是JDK没有拿到任何事件(READ、WRITE、CONNECT、ACCEPT),但此时select()方法不再选择阻塞了，而是选择返回了0，于是就会进入一种无限循环，导致CPU 100%.

这个问题的具体原因是：

在部分Linux的2.6的Kernel中。poll和epoll对于突然中断的连接socket会对返回的eventSet
事件集合置为POLLHUP或POLLERR，eventSet事件集合发生了变化，这就可能导致Selector会被唤醒。但是这个时候selector的select方法返回numKeys是0，所以下面本应该对key值进行遍历的事情处理根本执行不了，又回到最上面的while(true)循环，循环往复，不断的轮询，直到Linux系统出现100%的CPU情况，最终导致程序崩溃

Netty解决办法

对Selector的select操作周期进行统计，每完成一次空的select操作进行一次技术，若在某个周期内连续发生N次空轮询，则触发了epoll死循环bug.重建Selector,判断是否是其他线程发起的重建请求，若不是则将原SocketChannel从旧的Selector上去除注册，重新注册到新的Selector上，并将原来的Selector关闭，NioEventLoop的select方法中