Java延时实例分析：Lock vs Synchronized

这篇文章通过实例讨论了：

- java.concurrent.Lock创建的垃圾
- 比较Lock和synchronized
- 如何通过编程方式计算延时
- Lock和synchronized竞争带来的影响
- 延迟测试中由于遗漏（co-ordinated omission）可能对结果的影响

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

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

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

1. [GC (Allocation Failure) 16384K->1400K(62976K), 0.0016854 secs] 
2. [GC (Allocation Failure) 17784K->1072K(62976K), 0.0011939 secs] 
3. [GC (Allocation Failure) 17456K->1040K(62976K), 0.0008452 secs] 
4. [GC (Allocation Failure) 17424K->1104K(62976K), 0.0008338 secs] 
5. [GC (Allocation Failure) 17488K->1056K(61952K), 0.0008799 secs] 
6. [GC (Allocation Failure) 17440K->1024K(61952K), 0.0010529 secs] 
7. [GC (Allocation Failure) 17408K->1161K(61952K), 0.0012381 secs] 
8. [GC (Allocation Failure) 17545K->1097K(61440K), 0.0004592 secs] 
9. [GC (Allocation Failure) 16969K->1129K(61952K), 0.0004500 secs] 
10.  
11. [GC (Allocation Failure) 17001K->1129K(61952K), 0.0003857 secs] 

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

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

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

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

• 变得非结构化——比如，不会受块或方法的限制，允许你跨多个方法持有锁。

• 轮询锁

• 等待锁超时

• 配置失败策略

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

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

这段代码允许改变线程的数量（1个线程意味着不存在竞争）及竞争的数量。通过有遗漏（coordinated omission）和没有遗漏来衡量。
采用 Lock 或者 synchronised 来运行测试。

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

1. import org.junit.Test; 
2.  
3. import java.util.concurrent.locks.Lock; 
4. import java.util.concurrent.locks.ReentrantLock; 
5.  
6. public class LockVsSync { 
7.     private static final boolean COORDINATED_OMISSION = Boolean.getBoolean("coordinatedOmission"); 
8.     //Either run testing Lock or testing synchronized 
9.     private static final boolean IS_LOCK = Boolean.getBoolean("isLock"); 
10.     private static final int NUM_THREADS = Integer.getInteger("numThreads"); 
11.  
12.     <a href='http://www.jobbole.com/members/madao'>@Test</a> 
13.     public void test() throws InterruptedException { 
14.         Lock lock = new ReentrantLock(); 
15.         for (int t = 0; t &lt; NUM_THREADS; t++) { 
16.             if (t == 0) { 
17.                 //Set the first thread as the master which will be measured 
18.                 //设置第一个线程作为测量的线程 
19.                 //The other threads are only to cause contention 
20.                 //其他线程只是引起竞争 
21.                 Runner r = new Runner(lock, true); 
22.                 r.start(); 
23.             } else { 
24.                 Runner r = new Runner(lock, false); 
25.                 r.start(); 
26.             } 
27.         } 
28.  
29.         synchronized(this){ 
30.             //Hold the main thread from completing 
31.             wait(); 
32.         } 
33.  
34.     } 
35.  
36.     private void testLock(Lock rlock) { 
37.         rlock.lock(); 
38.         try { 
39.             for (int i = 0; i &lt; 2; i++) { 
40.                 double x = 10 / 4.5 + i; 
41.             } 
42.         } finally { 
43.             rlock.unlock(); 
44.         } 
45.     } 
46.  
47.     private synchronized void testSync() { 
48.         for (int i = 0; i &lt; 2; i++) { 
49.             double x = 10 / 4.5 + i; 
50.         } 
51.     } 
52.  
53.     class Runner extends Thread { 
54.         private Lock lock; 
55.         private boolean master; 
56.  
57.         public Runner(Lock lock, boolean master) { 
58.             this.lock = lock; 
59.             this.master = master; 
60.         } 
61.  
62.         @Override 
63.         public void run() { 
64.             Histogram histogram = null; 
65.             if (master) 
66.                 histogram = new Histogram(); 
67.  
68.             long rate = 1000;//expect 1 every microsecond 
69.             long now =0; 
70.             for (int i = -10000; i 0){ 
71.                     if(!COORDINATED_OMISSION) { 
72.                         now += rate; 
73.                         while(System.nanoTime() =0 &amp;&amp; master){ 
74.                     histogram.sample(System.nanoTime() - now); 
75.                 } 
76.             } 
77.             if (master) { 
78.                 System.out.println(histogram.toMicrosFormat()); 
79.                 System.exit(0); 
80.             } 
81.         } 
82.     } 
83. } 

结果如下：

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

• 采用微秒来衡量。

• 图形的顶部就是延迟的分布。

• 这是有竞争的测试，使用四个线程执行该程序。

• 这个测试是在8核的 MBP i7 上运行的。

• 每次测试迭代200,000,000次，并有10,000次预热。

• 根据吞吐率为每微妙迭代一次来调整遗漏。

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

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

当然，在有遗漏的情况下延迟会更高。

再次可以看到，在无竞争情况下，lock 和 synchronized 的性能是相同——这就没什么很惊奇了。

在竞争条件下，百分率为99%时，我们看到 synchronized 比 lock 表现好10X。在这之后，两者的表现基本是一致的。

我猜测这是因为GC回收的效率导致 lock 比 synchronised 要慢，大概每300-1200微妙发生一次GC回收。尤其是到达99%之后，慢得就相当明显了。在这个之后，延迟率可能与硬件和操作系统（OS）相关。但 是，这只是我个人的推断，没有做更深入的调查。

结论：

这篇文章更多的是怎么去测量和分析延迟。在竞争条件下，Lock的分配是一个非常有意思的话题，在真实世界里，这个问题也未必有什么实际的不同。

来源：51CTO