Java nio的一个严重BUG，导致cpu 100%

╰半夏微凉° 2022-02-17 01:46 351阅读 0赞

这个BUG会在linux上导致cpu 100%，使得nio server/client不可用，具体的详情可以看这里http://bugs.sun.com/bugdatabase/view\_bug.do?bug\_id=6403933  。令人失望的是这个BUG直到jdk 6u4才解决，sun的拖沓让人难以相信。这个BUG在server端容易出现，因为server端有频繁地接入断开连接。   
    使用jdk 6u4之前版本的nio框架都有这个隐患，除非你的框架很好地处理了这个可能的隐患。Grizzly的处理方式比较简单，也就是BUG报告里面提到的方式，在SelectionKey.cancel()之后马上进行了一次select调用将fd从poll(epoll)中移除：   
Java代码：

this.selectionKey.cancel();  
try \{  
            // cancel key,then select now to remove file descriptor  
            this.selector.selectNow();  
 \} catch (IOException e) \{  
         onException(e);  
        log.error("Selector selectNow fail", e);  
\}

实际上这样的解决方式还是留有隐患的，因为key的取消和这个selectNow操作很可能跟Selector.select操作并发地在进行，在两个操作之间仍然留有一个极小的时间窗口可能发生这个BUG。因此，你需要更安全地方式处理这个问题，jetty的处理方式是这样，连续的 select(timeout)操作没有阻塞并返回0，并且次数超过了一个指定阀值，那么就遍历整个key set，将key仍然有效并且interestOps等于0的所有key主动取消掉；如果在这次修正后，仍然继续出现select(timeout)不阻塞并且返回0的情况，那么就重新创建一个新的Selector，并将Old Selector的有效channel和对应的key转移到新的Selector上。

long before=now;  
                    int selected=selector.select(wait);  
                    now = System.currentTimeMillis();  
                    \_idleTimeout.setNow(now);  
                    \_timeout.setNow(now);

// Look for JVM bugs  
                    // [http://bugs.sun.com/bugdatabase/view\_bug.do?bug\_id=6403933][http_bugs.sun.com_bugdatabase_view_bug.do_bug_id_6403933]  
                    if (\_\_JVMBUG\_THRESHHOLD>0 && selected==0 && wait>\_\_JVMBUG\_THRESHHOLD && (now-before)<(wait/2) )  
                    \{  
                        \_jvmBug++;  
                        if (\_jvmBug>=(\_\_JVMBUG\_THRESHHOLD2))  
                        \{  
                            synchronized (this)  
                            \{  
                                \_lastJVMBug=now;  
                                                    // BLOODY SUN BUG !!!  Try refreshing the entire selector.  
                                final Selector new\_selector = Selector.open();  
                                for (SelectionKey k: selector.keys())  
                                \{  
                                    if (!k.isValid() || k.interestOps()==0)  
                                        continue;  
                                      
                                    final SelectableChannel channel = k.channel();  
                                    final Object attachment = k.attachment();  
                                      
                                    if (attachment==null)  
                                        addChange(channel);  
                                    else  
                                        addChange(channel,attachment);  
                                \}  
                                \_selector.close();  
                                \_selector=new\_selector;  
                                \_jvmBug=0;  
                                return;  
                            \}  
                        \}  
                        else if (\_jvmBug==\_\_JVMBUG\_THRESHHOLD || \_jvmBug==\_\_JVMBUG\_THRESHHOLD1)  
                        \{  
                            // Cancel keys with 0 interested ops  
                            for (SelectionKey k: selector.keys())  
                            \{  
                                if (k.isValid()&&k.interestOps()==0)  
                                \{  
                                    k.cancel();  
                                \}  
                            \}  
                            return;  
                        \}  
                    \}  
                    else  
                        \_jvmBug=0;

这个方案能比较好的在jdk 6u4之前的版本上解决这个BUG可能导致的问题。Mina和Netty没有看到有处理这个BUG的代码，如果我看错了，请留言告诉我。Yanf4j一直采用的是grizzly的方式，准备加上jetty的处理方案。当然，最简单的方案就是升级你的JDK。

俺实际上被这个BUG害的很惨, 因为降到了jdk 6u4 CPU仍然会时不时的增高, 原因是低版本的Jetty同样在这方面处理的不是很合理.   
    Jetty关于这个BUG的描述:[http://jira.codehaus.org/browse/JETTY-937][http_jira.codehaus.org_browse_JETTY-937], 用JETTY做为应用, JETTY1.6.22 + JDK 6U4俺现在测下来, CPU基本正常.

另外nio还有几个严重的bug，在实际运行中碰到了，sun在u18才修复，而现在u18还没正式发布。

[http://download.java.net/jdk6/6u18/promoted/b01/changes/JDK6u18.b01.list.html][http_download.java.net_jdk6_6u18_promoted_b01_changes_JDK6u18.b01.list.html]  
例如：[http://bugs.sun.com/view\_bug.do?bug\_id=6693490][http_bugs.sun.com_view_bug.do_bug_id_6693490]  
[http://bugs.sun.com/bugdatabase/view\_bug.do?bug\_id=6670302][http_bugs.sun.com_bugdatabase_view_bug.do_bug_id_6670302] 这个BUG跟我这里描述的相似，解决的方法也是一样。

[http://bugs.sun.com/view\_bug.do?bug\_id=6693490][http_bugs.sun.com_view_bug.do_bug_id_6693490] 这个BUG，一个间接影响也是关闭的channel一直有ready事件，select不阻塞并立即返回0，也就是导致CPU 100%，同样也是可以通过这里描述的方案解决的。

[http_bugs.sun.com_bugdatabase_view_bug.do_bug_id_6403933]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
[http_jira.codehaus.org_browse_JETTY-937]: http://jira.codehaus.org/browse/JETTY-937
[http_download.java.net_jdk6_6u18_promoted_b01_changes_JDK6u18.b01.list.html]: http://download.java.net/jdk6/6u18/promoted/b01/changes/JDK6u18.b01.list.html
[http_bugs.sun.com_view_bug.do_bug_id_6693490]: http://bugs.sun.com/view_bug.do?bug_id=6693490
[http_bugs.sun.com_bugdatabase_view_bug.do_bug_id_6670302]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6670302