java nio的一个严重BUG

这个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)中移除： 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                      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 :D

文章转自庄周梦蝶  ，原文发布时间2009-09-28

相关资源：敏捷开发V1.0.pptx