xmemcached 1.2.6.2紧急发布(升级到1.2.6.1的朋友注意)


    今年在阅读某个项目源码的时候看到DelayQueue的使用,xmemcached 1.2.6.1的重连任务也是采用DelayQueue管理,ReconnectRequest实现Delayed接口,我突然想起去review下xmc的源码,发现一个严重的BUG,原始代码如下:
public final class ReconnectRequest implements Delayed {
      
public long getDelay(TimeUnit unit) {
        
return  nextReconnectTimestamp - System.currentTimeMillis();
    }
}

    getDelay返回该任务还剩下多少时间可以被执行,将下次执行的时间戳减去当前时间即可,问题在于这里返回的是毫秒,而没有调用getDelay传入的TimeUnit做转换,在DelayQueue内部其实是用纳秒做单位交给Condition对象去等待
  for (;;) {
                E first 
= q.peek();
                
if (first == null) {
                    available.await();
                } 
else {
                    
long delay =  first.getDelay(TimeUnit.NANOSECONDS);
                    
if (delay > 0) {
                        
long tl = available.awaitNanos(delay);
                    } 
else {
                        E x 
= q.poll();
                        
assert x != null;
                        
if (q.size() != 0)
                            available.signalAll(); 
// wake up other takers
                        return x;

                    }
                }
            }
  
     最终导致的问题是,awaitNanos很快返回(awaitNanos接受的是纳秒,这里却传入毫秒),循环执行发现重新计算的delay仍然大于0,循环等到getDelay返回的越来越小直到0才执行相应的Task,,造成的现象是在重连的时候cpu占用率很高。

     单元测试的时候没有发现这个问题,主要是因为功能正常,没有关注资源消耗情况,因此惭愧地忽略了。

      解决的办法很简单,修改getDelay方法即可:
    public long getDelay(TimeUnit unit) {
        
return unit.convert(
                nextReconnectTimestamp 
- System.currentTimeMillis(),
                TimeUnit.MILLISECONDS);
    }


      这个BUG比较严重,已经升级1.2.6.1的朋友建议马上升级到1.2.6.2,使用maven的朋友只要修改版本即可,没有使用maven的请到这里下载。

文章转自庄周梦蝶  ,原文发布时间 2010-10-22

上一篇:Spark学习之Hadoop安装与测试


下一篇:小心升级!iOS 10.2可能会让更多iPhone突然关机