特别是在这篇文章中，我们将讨论：

• java.concurrent.Lock创建的垃圾
• 比较锁与同步
• 如何以编程方式测量延迟
• 争用对锁和同步的影响
• 协调遗漏对延迟测试的影响

回到我最喜欢的主题之一，垃圾创建/分配。 有关此主题的更多详细信息，请参阅我以前的文章（例如，性能优化 的第一条规则和重新访问 性能优化 的第一条规则：逃逸分析的效果 ）。 特别是为什么分配是理解性能问题的如此关键因素。

几天前，在尝试诊断JIT编译过程中分配的一些奇怪影响时，我遇到了一个问题，即java.util.concurrent.locks.ReentrantLock分配，但仅当处于竞争状态时才进行分配。 （这可以通过运行一个测试程序（如以下程序）轻松地证明，使用– verbosegc在Lock上创建竞争）。

下面的竞争锁的gc输出示例：

[GC (Allocation Failure)  16384K->1400K(62976K), 0.0016854 secs]
[GC (Allocation Failure)  17784K->1072K(62976K), 0.0011939 secs]
[GC (Allocation Failure)  17456K->1040K(62976K), 0.0008452 secs]
[GC (Allocation Failure)  17424K->1104K(62976K), 0.0008338 secs]
[GC (Allocation Failure)  17488K->1056K(61952K), 0.0008799 secs]
[GC (Allocation Failure)  17440K->1024K(61952K), 0.0010529 secs]
[GC (Allocation Failure)  17408K->1161K(61952K), 0.0012381 secs]
[GC (Allocation Failure)  17545K->1097K(61440K), 0.0004592 secs]
[GC (Allocation Failure)  16969K->1129K(61952K), 0.0004500 secs][GC (Allocation Failure)  17001K->1129K(61952K), 0.0003857 secs]

我想知道清理这些分配所必需的垃圾回收是否意味着在高度竞争的环境中，与使用内置的“ synchronized ”相比， Lock在同步方面是更糟糕的选择。

当然，这个问题比其他任何事情都更具学术性。 如果您确实非常在意延迟，那么您将永远（或者肯定永远不会）陷入需要大量线程锁定的情况。 不过，因为过程和结果很有趣，所以请和我在一起。

有点历史。 锁于2004年在Java 1.5版中引入。迫切需要将Lock与其他并发实用程序一起使用，以简化并发构造。 到那时为止，您已经处理了Object上的内置synchronized和wait()notify() 。

ReentrantLock除了提供synchronized功能外，还提供许多功能，
这仅仅是列举的一小部分：

• 非结构化–即您不限于在块或方法中使用它。 它使您可以通过几种方法持有锁。
• 锁定轮询
• 超时等待锁
• 可配置的公平政策

但是，它们在延迟测试方面的表现如何？

我在下面编写了一个简单的测试，比较了锁与同步的性能。

• 该代码使您可以更改线程数（1个线程表示没有争用），从而调整争用量。
• 在有或没有协同遗漏的情况下进行测量（请参阅以前的博客《协调遗漏的效果》 ）
• 运行测试锁定或同步测试。
• 要记录我的结果，您会注意到我使用了Histogram类。 这是由彼得·劳瑞（Peter Lawrey）创建的。 你可以找到类为纪事核心在实用这里 。

import org.junit.Test;import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;public class LockVsSync {private static final boolean COORDINATED_OMISSION = Boolean.getBoolean("coordinatedOmission");//Either run testing Lock or testing synchronizedprivate static final boolean IS_LOCK = Boolean.getBoolean("isLock");private static final int NUM_THREADS = Integer.getInteger("numThreads");@Testpublic void test() throws InterruptedException {Lock lock = new ReentrantLock();for (int t = 0; t < NUM_THREADS; t++) {if (t == 0) {//Set the first thread as the master which will be measured//The other threads are only to cause contentionRunner r = new Runner(lock, true);r.start();} else {Runner r = new Runner(lock, false);r.start();}}synchronized(this){//Hold the main thread from completingwait();}}private void testLock(Lock rlock) {rlock.lock();try {for (int i = 0; i < 2; i++) {double x = 10 / 4.5 + i;}} finally {rlock.unlock();}}private synchronized void testSync() {for (int i = 0; i < 2; i++) {double x = 10 / 4.5 + i;}}class Runner extends Thread {private Lock lock;private boolean master;public Runner(Lock lock, boolean master) {this.lock = lock;this.master = master;}@Overridepublic void run() {Histogram histogram = null;if (master)histogram = new Histogram();long rate = 1000;//expect 1 every microsecondlong now =0;for (int i = -10000; i < 200_000_000; i++) {if(i==0){now = System.nanoTime();} else if(i>0){if(!COORDINATED_OMISSION) {now += rate;while(System.nanoTime() < now);}elsenow = System.nanoTime();}if(IS_LOCK)testLock(lock);elsetestSync();if(i>=0 && master){histogram.sample(System.nanoTime() - now);}}if (master) {System.out.println(histogram.toMicrosFormat());System.exit(0);}}}
}

结果如下：

这些是忽略了遗漏的结果：

• 时间以微秒为单位。
• 延迟分布在图的顶部。
• 此测试中的争用意味着要使用4个线程运行该程序。
• 测试在具有8个逻辑CPU的MBP i7上运行。
• 每个测试包括200,000,000次迭代和10,000次迭代预热。
• 调整协调遗漏时的吞吐量为1迭代/微秒。

正如预期的那样，在没有争用的情况下，结果几乎相同。 JIT将优化锁定并进行同步。

在较低的百分位数中，使用Lock进行争用稍微快一些，但实际上又不是很多。 因此，即使有许多较小的垃圾收集，它们似乎也没有显着降低锁的速度。 如果有的话，总体上Lock会稍微快一点。

这些是为协调省略而调整的结果。

这些数字当然更高，因为它们考虑了引起的真正延迟。

同样，在没有争用的情况下，锁和同步执行相同的操作–在那里没有很大的惊喜。

有了争用，现在我们可以看到高达99％的百分比的同步锁定性能超出10倍。 之后，时间几乎相同。

我可以推测，与同步相比，gc集合的影响（介于300-1200微秒之间）是导致锁缓慢的原因。 尤其是因为速度下降仅出现到第99个百分位时才明显–在此之后，延迟可能会降到硬件和操作系统上。 但是，这只是我的推测，无需进一步调查。

结论

这篇文章的收获更多是关于衡量和分析延迟的过程。 有趣的是， Lock在竞争时进行分配，但不太可能在现实世界中产生任何实际变化

翻译自: https://www.javacodegeeks.com/2015/08/a-case-study-in-analysing-latency-lock-vs-synchronized.html