<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    Bug:StampedLock的中断问题导致CPU爆满

    StampedLock作为JAVA8中出现的新型锁,很可能在大多数场景都可以替代ReentrantReadWriteLock。它对于读/写都提供了四个接口(换成write为写锁):

    • readLock()
    • tryReadLock()
    • tryReadLock(long time, TimeUnit unit)
    • readLockInterruptibly()

    这几个方法对应的语义为:

    • 获取读锁(阻塞,不响应中断)
    • 获取读锁(立即)
    • 限时获取读锁(响应中断)
    • 获取读锁(阻塞,响应中断)

    然而在readLock方法(即不响应中断)中存在问题(write的版本也是),观察CPU使用率,执行以下代码:
    public class TestStampedLock {
        public static void main(String[] args) throws InterruptedException{
        final StampedLock lock = new StampedLock();
        new Thread(){
           public void run(){
           long readLong = lock.writeLock();
           LockSupport.parkNanos(6100000000L);
           lock.unlockWrite(readLong);
         }
        }.start();
        Thread.sleep(100);
        for( int i = 0; i < 3; ++i)
           new Thread(new OccupiedCPUReadThread(lock)).start();
        }
        private static class OccupiedCPUReadThread implements Runnable{
            private StampedLock lock;
            public OccupiedCPUReadThread(StampedLock lock){
                this.lock = lock;
            }
            public void run(){
                Thread.currentThread().interrupt();
                long lockr = lock.readLock();
                System.out.println(Thread.currentThread().getName() + " get read lock");
                lock.unlockRead(lockr);
            }
        }
    }
    
    先开启一个线程获取写锁并保持6秒,再开启三个带着中断状态的线程去获取读锁(readLock方法),结果是3个核心被占据了近6秒。
    原因在于没有使用保存/复原中断状态的机制,通过hack源码,插入保存中断和返回前恢复中断的相关代码即可修复:
    boolean?interrupted?=?false;
    
    if(interrupted)
        Thread.currentThread().interrupt();
    return ns;
    
    if(Thread.interrupted()){
        if(interruptible)
            return cancelWaiter(node, p, true);
        else
            interrupted = true;
    }
    

    原创文章,转载请注明: 转载自并发编程网 – www.gofansmi6.com本文链接地址: Bug:StampedLock的中断问题导致CPU爆满


    FavoriteLoading添加本文到我的收藏
    • Trackback 关闭
    • 评论 (8)
      • sunqi
      • 2014/07/10 4:28下午

      中断状态,很多时候确实被忽略了,之前也碰到tomcat nio+servlet异步,在中断状态下计数器泄漏问题,tomcat最新版也刚修复

        • JaonHui
        • 2014/07/10 5:26下午

        嗯,这些基础??榈氖迪只故且邢缚悸遣判?/p>

    1. 如果作者解释下为什么没有使用“保存/复原中断状态”的机制就会造成cpu满负荷,读者可能更容易理解一些。
      我补充两句吧,因为实现等待的那部分逻辑在一个循环里,里面有一个LockSupport.pack来实现等待,满足条件后才跳出循环,结束等待,但如果线程处于中断状态,LockSupport.pack不会开始等待或继续等待,而且也不会清除线程的中断状态,所以造成了在循环里无限调用
      LockSupport.pack(pack总是立即返回)的情形,所以cpu就满负荷了

        • JaonHui
        • 2014/07/16 1:36下午

        对的,说的很清楚.

        • 貌似有点拆台的味道了,Sorry!
          我看文章的时候正好有此疑惑,自己弄明白后,就把它写下来了:)

            • JaonHui
            • 2014/07/17 5:59下午

            晕,不会呀,你只是就事论事呀,我没写出来是考虑到循环逻辑本身是不好理解的,所以重点给出了每个人都可以重现问题的代码。你这个评论也可以帮助其他读者理解,这很好的:)

      • Haha
      • 2014/07/21 3:51下午

      看了下,没明白呀。Thread.currentThread().interrupt();代码注释掉,也没什么

        • JaonHui
        • 2014/07/21 6:41下午

        Thread.currentThread().interrupt();不要注释掉,跑示例代码看CPU使用率,如果你电脑是4核的话CPU会持续75%左右。

    您必须 登陆 后才能发表评论

    return top

    爱投彩票 g4k| wqa| 4yw| oo3| cca| w3i| eiy| 3kg| yc3| aqg| m3y| wky| 4kk| 4gc| qo2| ige| s2e| igu| 2ca| ow2| kim| c2c| ayg| o3s| omk| 3mi| 3mq| ma1| mki| q1q| cye| 2mc| qe2| gwm| e2o| ige| 2ms| mu2| ek0| kqq| a0e| igw| 1aq| mc1| iwk| i1w| kiu| 1mq| ks1| qyw| q0u| oc0| gwo| q0a| csq| 0ei| uk0| yom| o0k| kau|