Java延时实例分析：Lock vs Synchronized

最新推荐文章于 2024-04-14 20:19:43 发布

哲洛别闹

最新推荐文章于 2024-04-14 20:19:43 发布

阅读量150

点赞数

原文链接：http://www.importnew.com/16596.html

版权

0?wx_fmt=png

- java.concurrent.Lock创建的垃圾

回到我最喜欢的一个主题：垃圾的创建与分配。可以从我以前的文章（如：性能优化的首要法则和重视性能优化首要法则：逃逸分析的效果）获取更多关于这个议题的细节。尤其弄懂在性能问题上，为什么分配是如此重要的因素。

几天前，当我诊断一些 JIT 编译期间奇怪的分配问题时，发现 java.util.concurrent.locks.ReentrantLock 的分配有问题，不过这只在竞争条件下出现。（这一点很容易证明，只要运行一个在 Lock 上建立竞争并指定 –verbosegc 参数测试程序（类似下面的程序））。

示例是在有 Lock 竞争时 GC 的输出结果：

0?wx_fmt=png

我怀疑是否是在垃圾回收时必须对清理 Lock 上分配的空间，在高度竞争的环境下，将会选择一种比内建的 ‘synchronized‘ 更坏的同步策略。

当然，这个问题比其他任何问题都更加学术。如果你确实非常关心延迟，你会发现自己从来不会（或者绝不应该）有这样一种情况会需要这么多的线程锁。不过，请继续跟我一起探究这个问题，因为这个过程和结果都非常有趣。

简史：锁是2004年，在Java 1.5中引入的。由于对简单并发结构的迫切需要，锁以及其他并发工具因此而诞生。在这之前，你不得不通过内建的 synchronized 和 Object 的 wait()、notify() 方法来控制并发。

ReentrantLock 提供许多比 synchronized 更好的功能，下面是一些例子：

变得非结构化——比如，不会受块或方法的限制，允许你跨多个方法持有锁。
轮询锁
等待锁超时
配置失败策略

但是它们在延迟测试中有什么作用呢？

我写了一个简单的测试来比较 Lock 和 synchronized 的性能。

这段代码允许改变线程的数量（1个线程意味着不存在竞争）及竞争的数量。通过有遗漏（coordinated omission）和没有遗漏来衡量。

为了记录结果，我使用了 Histogram 类。该类是 Peter Lawrey 创建的。你可以在 Chronicle-Core 的工具类中找到该类。

0?wx_fmt=png

结果如下：

这是没有遗漏（co-ordinated omission）的结果：

采用微秒来衡量。
图形的顶部就是延迟的分布。
这是有竞争的测试，使用四个线程执行该程序。
这个测试是在8核的 MBP i7 上运行的。
每次测试迭代200,000,000次，并有10,000次预热。
根据吞吐率为每微妙迭代一次来调整遗漏。

0?wx_fmt=jpeg

如我们所期望的一样，没有竞争时，结果是基本相同的。JIT 已经对 Lock 和 synchronized 进行了优化。在有竞争的情况下，占用百分比低的时候，使用 Lock 会稍微快一点，但是这种差别真的很小。所以，即使存在很多的年青代GC（minor GC），它们也没有显著的降低 Lock 效率。如果都是轻量级的 Lock，总体上就比较快了。

这是调整为有遗漏情况后的结果。

0?wx_fmt=jpeg