Java延時例項分析：Lock vs Synchronized

這篇文章通過例項討論了：

- java.concurrent.Lock建立的垃圾
- 比較Lock和synchronized
- 如何通過程式設計方式計算延時
- Lock和synchronized競爭帶來的影響
- 延遲測試中由於遺漏（co-ordinated omission）可能對結果的影響

回到我最喜歡的一個主題：垃圾的建立與分配。可以從我以前的文章（如：效能優化的首要法則和重視效能優化首要法則：逃逸分析的效果）獲取更多關於這個議題的細節。尤其弄懂在效能問題上，為什麼分配是如此重要的因素。

幾天前，當我診斷一些 JIT 編譯期間奇怪的分配問題時，發現 java.util.concurrent.locks.ReentrantLock 的分配有問題，不過這隻在競爭條件下出現。（這一點很容易證明，只要執行一個在 Lock 上建立競爭並指定 –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]

我懷疑是否是在垃圾回收時必須對清理 Lock 上分配的空間，在高度競爭的環境下，將會選擇一種比內建的 ‘synchronized‘ 更壞的同步策略。

當然，這個問題比其他任何問題都更加學術。如果你確實非常關心延遲，你會發現自己從來不會（或者絕不應該）有這樣一種情況會需要這麼多的執行緒鎖。不過，請繼續跟我一起探究這個問題，因為這個過程和結果都非常有趣。

簡史：鎖是2004年，在Java 1.5中引入的。由於對簡單併發結構的迫切需要，鎖以及其他併發工具因此而誕生。在這之前，你不得不通過內建的 synchronized 和 Object 的 wait()、notify() 方法來控制併發。

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

• 變得非結構化——比如，不會受塊或方法的限制，允許你跨多個方法持有鎖。
• 輪詢鎖
• 等待鎖超時
• 配置失敗策略

但是它們在延遲測試中有什麼作用呢？

我寫了一個簡單的測試來比較 Lock 和 synchronized 的效能。

這段程式碼允許改變執行緒的數量（1個執行緒意味著不存在競爭）及競爭的數量。通過有遺漏（coordinated omission）和沒有遺漏來衡量。
採用 Lock 或者 synchronised 來執行測試。

為了記錄結果，我使用了 Histogram 類。該類是 Peter Lawrey 建立的。你可以在 Chronicle-Core 的工具類中找到該類。

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 synchronized
    private static final boolean IS_LOCK = Boolean.getBoolean("isLock");
    private static final int NUM_THREADS = Integer.getInteger("numThreads");

    <a href='http://www.jobbole.com/members/madao'>@Test</a>
    public void test() throws InterruptedException {
        Lock lock = new ReentrantLock();
        for (int t = 0; t &lt; NUM_THREADS; t++) {
            if (t == 0) {
                //Set the first thread as the master which will be measured
                //設定第一個執行緒作為測量的執行緒
                //The other threads are only to cause contention
                //其他執行緒只是引起競爭
                Runner r = new Runner(lock, true);
                r.start();
            } else {
                Runner r = new Runner(lock, false);
                r.start();
            }
        }

        synchronized(this){
            //Hold the main thread from completing
            wait();
        }

    }

    private void testLock(Lock rlock) {
        rlock.lock();
        try {
            for (int i = 0; i &lt; 2; i++) {
                double x = 10 / 4.5 + i;
            }
        } finally {
            rlock.unlock();
        }
    }

    private synchronized void testSync() {
        for (int i = 0; i &lt; 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;
        }

        @Override
        public void run() {
            Histogram histogram = null;
            if (master)
                histogram = new Histogram();

            long rate = 1000;//expect 1 every microsecond
            long now =0;
            for (int i = -10000; i 0){
                    if(!COORDINATED_OMISSION) {
                        now += rate;
                        while(System.nanoTime() =0 &amp;&amp; master){
                    histogram.sample(System.nanoTime() - now);
                }
            }
            if (master) {
                System.out.println(histogram.toMicrosFormat());
                System.exit(0);
            }
        }
    }
}

結果如下：

這是沒有遺漏（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的分配是一個非常有意思的話題，在真實世界裡，這個問題也未必有什麼實際的不同。