- java.concurrent.Lock创建的垃圾 - 比较Lock和synchronized - 如何通过编程方式计算延时 - Lock和synchronized竞争带来的影响 - 延迟测试中由于遗漏(co-ordinated omission)可能对结果的影响
回到我最喜欢的一个主题:垃圾的创建与分配。可以从我以前的文章(如:性能优化的首要法则和重视性能优化首要法则:逃逸分析的效果)获取更多关于这个议题的细节。尤其弄懂在性能问题上,为什么分配是如此重要的因素。
几天前,当我诊断一些 JIT 编译期间奇怪的分配问题时,发现 java.util.concurrent.locks.ReentrantLock 的分配有问题,不过这只在竞争条件下出现。(这一点很容易证明,只要运行一个在 Lock 上建立竞争并指定 –verbosegc 参数测试程序(类似下面的程序))。
示例是在有 Lock 竞争时 GC 的输出结果:
我怀疑是否是在垃圾回收时必须对清理 Lock 上分配的空间,在高度竞争的环境下,将会选择一种比内建的 ‘synchronized‘ 更坏的同步策略。
当然,这个问题比其他任何问题都更加学术。如果你确实非常关心延迟,你会发现自己从来不会(或者绝不应该)有这样一种情况会需要这么多的线程锁。不过,请继续跟我一起探究这个问题,因为这个过程和结果都非常有趣。
简史:锁是2004年,在Java 1.5中引入的。由于对简单并发结构的迫切需要,锁以及其他并发工具因此而诞生。在这之前,你不得不通过内建的 synchronized 和 Object 的 wait()、notify() 方法来控制并发。
ReentrantLock 提供许多比 synchronized 更好的功能,下面是一些例子:
但是它们在延迟测试中有什么作用呢?
我写了一个简单的测试来比较 Lock 和 synchronized 的性能。
这段代码允许改变线程的数量(1个线程意味着不存在竞争)及竞争的数量。通过有遗漏(coordinated omission)和没有遗漏来衡量。 采用 Lock 或者 synchronised 来运行测试。
为了记录结果,我使用了 Histogram 类。该类是 Peter Lawrey 创建的。你可以在 Chronicle-Core 的工具类中找到该类。
结果如下:
这是没有遗漏(co-ordinated omission)的结果:
如我们所期望的一样,没有竞争时,结果是基本相同的。JIT 已经对 Lock 和 synchronized 进行了优化。在有竞争的情况下,占用百分比低的时候,使用 Lock 会稍微快一点,但是这种差别真的很小。所以,即使存在很多的年青代GC(minor GC),它们也没有显著的降低 Lock 效率。如果都是轻量级的 Lock,总体上就比较快了。
这是调整为有遗漏情况后的结果。
当然,在有遗漏的情况下延迟会更高。
再次可以看到,在无竞争情况下,lock 和 synchronized 的性能是相同——这就没什么很惊奇了。
在竞争条件下,百分率为99%时,我们看到 synchronized 比 lock 表现好10X。在这之后,两者的表现基本是一致的。
我猜测这是因为GC回收的效率导致 lock 比 synchronised 要慢,大概每300-1200微妙发生一次GC回收。尤其是到达99%之后,慢得就相当明显了。在这个之后,延迟率可能与硬件和操作系统(OS)相关。但是,这只是我个人的推断,没有做更深入的调查。
结论:
这篇文章更多的是怎么去测量和分析延迟。在竞争条件下,Lock的分配是一个非常有意思的话题,在真实世界里,这个问题也未必有什么实际的不同。
原文链接: javacodegeeks 翻译: ImportNew.com - paddx 译文链接: http://www.importnew.com/16596.html