Java nio的一个严重BUG

最新推荐文章于 2024-05-20 11:02:13 发布

最新推荐文章于 2024-05-20 11:02:13 发布 · 162 阅读

文章标签：

#java #jira #epoll

多线程同时被 3 个专栏收录

1 篇文章

订阅专栏

server

1 篇文章

订阅专栏

NIO

1 篇文章

订阅专栏

本文详细介绍了 Java NIO 在 Linux 平台上导致 CPU 使用率飙升至 100% 的 BUG，并提供了 Grizzly 和 Jetty 的解决方案。此问题常见于服务端频繁的连接建立与断开场景。

这个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{
//cancelkey,thenselectnowtoremovefiledescriptor
this.selector.selectNow();
}catch(IOExceptione){
onException(e);
log.error("SelectorselectNowfail",e);
}

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

Java代码

longbefore=now;
intselected=selector.select(wait);
now=System.currentTimeMillis();
_idleTimeout.setNow(now);
_timeout.setNow(now);
//LookforJVMbugs
//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;//BLOODYSUNBUG!!!Tryrefreshingtheentireselector.
finalSelectornew_selector=Selector.open();
for(SelectionKeyk:selector.keys())
{
if(!k.isValid()||k.interestOps()==0)
continue;
finalSelectableChannelchannel=k.channel();
finalObjectattachment=k.attachment();
if(attachment==null)
addChange(channel);
else
addChange(channel,attachment);
}
_selector.close();
_selector=new_selector;
_jvmBug=0;
return;
}
}
elseif(_jvmBug==__JVMBUG_THRESHHOLD||_jvmBug==__JVMBUG_THRESHHOLD1)
{
//Cancelkeyswith0interestedops
for(SelectionKeyk:selector.keys())
{
if(k.isValid()&&k.interestOps()==0)
{
k.cancel();
}
}
return;
}
}
else
_jvmBug=0;

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
                    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，用JETTY做为应用, JETTY1.6.22 + JDK 6U4俺现在测下来, CPU基本正常.