Java理论与实践: JDK 5.0中更灵活、更具可伸缩性的锁定机制(2)
时间:2011-02-12 IBM Brian Goetz清单 1. 用 ReentrantLock 保护代码块。
Lock lock = new ReentrantLock();
lock.lock();
try {
// update object state
}
finally {
lock.unlock();
}
除此之外，与目前的 synchronized 实现相比，争用下的 ReentrantLock 实现更具可伸缩性。（在未来的 JVM 版本中，synchronized 的争用性能很有可能会获得提高。）这意味着当许多线程都在争用同一个锁时，使用 ReentrantLock 的总体开支通常要比 synchronized 少得多。
比较 ReentrantLock 和 synchronized 的可伸缩性
Tim Peierls 用一个简单的线性全等伪随机数生成器（PRNG）构建了一个简单的评测，用它来测量 synchronized 和 Lock 之间相对的可伸缩性。这个示例很好，因为每次调用 nextRandom() 时，PRNG 都确实在做一些工作，所以这个基准程序实际上是在测量一个合理的、真实的 synchronized 和 Lock 应用程序，而不是测试纯粹纸上谈兵或者什么也不做的代码（就像许多所谓的基准程序一样。）
在这个基准程序中，有一个 PseudoRandom 的接口，它只有一个方法 nextRandom(int bound) 。该接口与 java.util.Random 类的功能非常类似。因为在生成下一个随机数时，PRNG 用最新生成的数字作为输入，而且把最后生成的数字作为一个实例变量来维护，其重点在于让更新这个状态的代码段不被其他线程抢占，所以我要用某种形式的锁定来确保这一点。（ java.util.Random 类也可以做到这点。）我们为 PseudoRandom 构建了两个实现；一个使用 syncronized，另一个使用 java.util.concurrent.ReentrantLock 。驱动程序生成了大量线程，每个线程都疯狂地争夺时间片，然后计算不同版本每秒能执行多少轮。图 1 和 图 2 总结了不同线程数量的结果。这个评测并不完美，而且只在两个系统上运行了（一个是双 Xeon 运行超线程 Linux，另一个是单处理器 Windows 系统），但是，应当足以表现 synchronized 与 ReentrantLock 相比所具有的伸缩性优势了。
图 1. synchronized 和 Lock 的吞吐率，单 CPU
图 2. synchronized 和 Lock 的吞吐率（标准化之后），4 个 CPU
图 1 和图 2 中的图表以每
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
