Java中延時Lock vs Synchronized的實例分析

本篇文章給大家分享的是有關Java中延時Lock vs Synchronized的實例分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

幾天前，當我診斷一些 JIT 編譯期間奇怪的分配問題時，發(fā)現(xiàn)  java.util.concurrent.locks.ReentrantLock  的分配有問題，不過這只在競爭條件下出現(xiàn)。（這一點很容易證明，只要運行一個在 Lock 上建立競爭并指定 –verbosegc  參數(shù)測試程序（類似下面的程序））。

示例是在有 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 上分配的空間，在高度競爭的環(huán)境下，將會選擇一種比內建的 ‘synchronized‘ 更壞的同步策略。

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

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

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

• 變得非結構化——比如，不會受塊或方法的限制，允許你跨多個方法持有鎖。

• 輪詢鎖

• 等待鎖超時

• 配置失敗策略

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

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

這段代碼允許改變線程的數(shù)量（1個線程意味著不存在競爭）及競爭的數(shù)量。通過有遺漏（coordinated omission）和沒有遺漏來衡量。
采用 Lock 或者 synchronised 來運行測試。

為了記錄結果，我使用了 Histogram 類。該類是 Peter Lawrey 創(chuàng)建的。你可以在 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）的結果：

• 采用微秒來衡量。

• 圖形的頂部就是延遲的分布。

• 這是有競爭的測試，使用四個線程執(zhí)行該程序。

• 這個測試是在8核的 MBP i7 上運行的。

• 每次測試迭代200,000,000次，并有10,000次預熱。

• 根據(jù)吞吐率為每微妙迭代一次來調整遺漏。

如我們所期望的一樣，沒有競爭時，結果是基本相同的。JIT 已經(jīng)對 Lock 和 synchronized  進行了優(yōu)化。在有競爭的情況下，占用百分比低的時候，使用 Lock 會稍微快一點，但是這種差別真的很小。所以，即使存在很多的年青代GC（minor  GC），它們也沒有顯著的降低 Lock 效率。如果都是輕量級的 Lock，總體上就比較快了。

這是調整為有遺漏情況后的結果。

當然，在有遺漏的情況下延遲會更高。

再次可以看到，在無競爭情況下，lock 和 synchronized 的性能是相同——這就沒什么很驚奇了。

在競爭條件下，百分率為99%時，我們看到 synchronized 比 lock 表現(xiàn)好10X。在這之后，兩者的表現(xiàn)基本是一致的。

我猜測這是因為GC回收的效率導致 lock 比 synchronised  要慢，大概每300-1200微妙發(fā)生一次GC回收。尤其是到達99%之后，慢得就相當明顯了。在這個之后，延遲率可能與硬件和操作系統(tǒng)（OS）相關。但 是，這只是我個人的推斷，沒有做更深入的調查。

以上就是Java中延時Lock vs Synchronized的實例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。