欧美一级特黄大片做受成人-亚洲成人一区二区电影-激情熟女一区二区三区-日韩专区欧美专区国产专区

Java中延時(shí)LockvsSynchronized的實(shí)例分析

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

公司主營(yíng)業(yè)務(wù):成都網(wǎng)站建設(shè)、網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化,感謝他們對(duì)我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出都蘭免費(fèi)做網(wǎng)站回饋大家。

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

示例是在有 Lock 競(jìng)爭(zhēng)時(shí) GC 的輸出結(jié)果:

[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]

我懷疑是否是在垃圾回收時(shí)必須對(duì)清理 Lock 上分配的空間,在高度競(jìng)爭(zhēng)的環(huán)境下,將會(huì)選擇一種比內(nèi)建的 ‘synchronized‘ 更壞的同步策略。

當(dāng)然,這個(gè)問題比其他任何問題都更加學(xué)術(shù)。如果你確實(shí)非常關(guān)心延遲,你會(huì)發(fā)現(xiàn)自己從來不會(huì)(或者絕不應(yīng)該)有這樣一種情況會(huì)需要這么多的線程鎖。不過,請(qǐng)繼續(xù)跟我一起探究這個(gè)問題,因?yàn)檫@個(gè)過程和結(jié)果都非常有趣。

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

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

  • 變得非結(jié)構(gòu)化——比如,不會(huì)受塊或方法的限制,允許你跨多個(gè)方法持有鎖。

  • 輪詢鎖

  • 等待鎖超時(shí)

  • 配置失敗策略

但是它們?cè)谘舆t測(cè)試中有什么作用呢?

我寫了一個(gè)簡(jiǎn)單的測(cè)試來比較 Lock 和 synchronized 的性能。

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

為了記錄結(jié)果,我使用了 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                 //設(shè)置***個(gè)線程作為測(cè)量的線程                 //The other threads are only to cause contention                 //其他線程只是引起競(jìng)爭(zhēng)                 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);             }         }     } }

結(jié)果如下:

這是沒有遺漏(co-ordinated omission)的結(jié)果:

  • 采用微秒來衡量。

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

  • 這是有競(jìng)爭(zhēng)的測(cè)試,使用四個(gè)線程執(zhí)行該程序。

  • 這個(gè)測(cè)試是在8核的 MBP i7 上運(yùn)行的。

  • 每次測(cè)試迭代200,000,000次,并有10,000次預(yù)熱。

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

Java中延時(shí)Lock vs Synchronized的實(shí)例分析

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

這是調(diào)整為有遺漏情況后的結(jié)果。

Java中延時(shí)Lock vs Synchronized的實(shí)例分析

當(dāng)然,在有遺漏的情況下延遲會(huì)更高。

再次可以看到,在無競(jìng)爭(zhēng)情況下,lock 和 synchronized 的性能是相同&mdash;&mdash;這就沒什么很驚奇了。

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

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

以上就是Java中延時(shí)Lock vs Synchronized的實(shí)例分析,小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘9ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享名稱:Java中延時(shí)LockvsSynchronized的實(shí)例分析
分享網(wǎng)址:http://aaarwkj.com/article22/ggpgcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站制作軟件開發(fā)、商城網(wǎng)站網(wǎng)站營(yíng)銷、網(wǎng)站排名、Google

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)公司
国产亚洲精品久久综合阿香| 日韩不伦高清一区二区三区| 日本加勒比中文在线观看| 免费看av网站一区二区| 国产精品免费视频能看的| 可以免费看的欧美黄片| 少妇被按摩高潮在线观看| 日韩黄av在线免费观看| 免费无码不卡av一区二区| 日韩欧美亚洲综合久久精品| 久久精品一区二区婷婷| 日本和亚洲的香蕉视频| 夫妻性生活短是什么原因| 亚洲激情人妻小说网| 亚洲日本成人av在线观看| 亚洲一区成人免费电影| 日本少妇入口一区二区| 97人妻人人澡人人添人人爽| 欧美日韩国产91在线| 欧美劲爆三级免费观看| 国产精品视频一区二区噜| 久久这里只有精品伊人网| 日本成人午夜在线观看| 另类视频在线免费观看| 亚洲毛片一区二区在线| 女同毛片一区二区三区| 本色啪啪人妻夜嗨嗨av| 亚洲中文字幕偷拍色图| 中文色婷婷国产精品视频| 97在线资源视频播放| 蜜桃少妇人妻一区二区视频| 日日夜夜精品天天综合| 粉嫩国产精品一区二区| 国产日本福利在线综合网| 亚洲日本av一区二区| 一区二区亚洲成人精品| 国产精品久久久在线视频| 国产精品久久久av大片| 美女呻吟被爽到高潮在线| 亚洲国产精品区一区二区| 欧美日韩国产成人激情|