NIO的epoll空轮询bug
JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK1.6版本的update18修复了该问题，但是直到JDK1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有被根本解决。该BUG以及与该BUG相关的问题单可以参见以下链接内容。
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933
参考：https://github.com/netty/netty/issues/327
参考：https://www.jianshu.com/p/d0f06b13e2fb
参考：http://blog.jobbole.com/105564/
参考：http://blog.csdn.net/xyls12345/article/details/26571699
Selector BUG出现的原因
若Selector的轮询结果为空，也没有wakeup或新消息处理，则发生空轮询，CPU使用率100%，
Netty的解决办法
对Selector的select操作周期进行统计，每完成一次空的select操作进行一次计数，
若在某个周期内连续发生N次空轮询，则触发了epoll死循环bug。
重建Selector，判断是否是其他线程发起的重建请求，若不是则将原SocketChannel从旧的Selector上去除注册，重新注册到新的Selector上，并将原来的Selector关闭。
参考：http://blog.csdn.net/baiye_xing/article/details/73351330
前面讲到了epoll的一些机制，与select和poll等传统古老的IO多路复用机制的一些区别，这些区别实质可以总结为一句话，
就是epoll将重要的基于事件的fd集合放在了内核中来完成，因为内核是高效的，所以很多关于fd事件监听集合的操作也是高效的，
不方便的就是，因为在内核中，所以我们需要通过系统调用来调用关于fd操作集合，而不是直接自己攒一个。
如果在linux中，epoll在JDK6中还需要配置，在后续的版本中为JDK的NIO提供了默认的实现，但是epoll在JDK中的实现却是漏洞百出的，
bug非常的多，比较容易复现并且被众多人诟病的就是epoll轮询的处理方法。
sun的bug列表为：
JDK-6670302 (se) NIO selector wakes up with 0 selected keys infinitely [lnx 2.4]
JDK-6670302 : (se) NIO selector wakes up with 0 selected keys infinitely [lnx 2.4]
===》这个bug的描述内容为，在NIO的selector中，即使是关注的select轮询事件的key为0的话，NIO照样不断的从select本应该阻塞的
情况中wake up出来，也就是下图中的红色阻塞的部分：
然后，因为selector的select方法，返回numKeys是0，所以下面本应该对key值进行遍历的事件处理根本执行不了，又回到最上面的while(true)循环，循环往复，不断的轮询，直到linux系统出现100%的CPU情况，其它执行任务干不了活，
最终导致程序崩溃。
==》从这个bug上来看，这个绝对是JDK中的问题，select方法就应该是阻塞的，没有key事件过来，那么就不应该返回，和应用程序的写法没有任何的关系，与之相差不多的一个bug给出了解决的方案：