mac 大寫鎖定延遲

特別是在這篇文章中，我們將討論：

• java.concurrent.Lock創(chuàng)建的垃圾
• 比較鎖與同步
• 如何以編程方式測量延遲
• 爭用對(duì)鎖和同步的影響
• 遺漏對(duì)延遲測試的影響

回到我最喜歡的主題之一，垃圾創(chuàng)建/分配。 有關(guān)此主題的更多詳細(xì)信息，請(qǐng)參見我以前的文章（例如，性能優(yōu)化 的第一條規(guī)則和重新訪問 性能優(yōu)化 的第一條規(guī)則：逃逸分析的效果 ）。 特別是為什么分配是理解性能問題的如此關(guān)鍵因素。

幾天前，我在嘗試診斷JIT編譯過程中分配的一些奇怪影響時(shí)遇到了什么，這是java.util.concurrent.locks.ReentrantLock分配的，但僅當(dāng)處于競爭狀態(tài)時(shí)才分配。 （這可以通過運(yùn)行一個(gè)測試程序（如下面的程序）很容易地證明，該程序使用– verbosegc在Lock上創(chuàng)建了爭用）。

下面的競爭鎖的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]

我想知道清理這些分配所必需的垃圾回收是否意味著在高度競爭的環(huán)境中，與使用內(nèi)置的“ synchronized ”相比， Lock在同步方面是更糟糕的選擇。

當(dāng)然，這個(gè)問題比其他任何事情都更具學(xué)術(shù)性。 如果您確實(shí)非常關(guān)心延遲，那么您將永遠(yuǎn)（或者肯定永遠(yuǎn)不會(huì)）陷入需要大量線程鎖定的情況。 不過，因?yàn)檫^程和結(jié)果很有趣，所以請(qǐng)和我在一起。

有點(diǎn)歷史。 2004年，Java 1.5中引入了Lock 。為了簡化并發(fā)構(gòu)造，迫切需要將Lock與其他并發(fā)實(shí)用程序一起使用。 到目前為止，您已經(jīng)處理了Object上的內(nèi)置synchronized和wait()notify() 。

ReentrantLock除了提供synchronized功能外，還提供許多功能，
這僅僅是列舉的一小部分：

• 非結(jié)構(gòu)化–即您不限于在塊或方法中使用它。 它使您可以通過幾種方法持有鎖。
• 鎖定輪詢
• 超時(shí)等待鎖
• 可配置的公平政策

但是，它們?nèi)绾芜M(jìn)行延遲測試呢？

我在下面編寫了一個(gè)簡單的測試，比較了鎖與同步的性能。

• 該代碼使您可以更改線程數(shù)（1個(gè)線程表示沒有爭用），從而調(diào)整爭用量。
• 在有或沒有協(xié)同遺漏的情況下進(jìn)行測量（請(qǐng)參閱以前的博客《協(xié)調(diào)遺漏的效果》 ）
• 運(yùn)行測試鎖定或同步測試。
• 要記錄我的結(jié)果，您會(huì)注意到我使用了Histogram類。 這是由彼得·勞瑞（Peter Lawrey）創(chuàng)建的。 你可以找到類為紀(jì)事核心在實(shí)用這里 。

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);}}} }

結(jié)果如下：

這些是忽略了遺漏的結(jié)果：

• 時(shí)間以微秒為單位。
• 延遲分布在圖的頂部。
• 該測試中的爭用意味著要使用4個(gè)線程運(yùn)行該程序。
• 測試是在具有8個(gè)邏輯CPU的MBP i7上運(yùn)行的。
• 每個(gè)測試包括200,000,000次迭代和10,000次迭代預(yù)熱。
• 調(diào)整協(xié)調(diào)遺漏時(shí)的吞吐量為1迭代/微秒。

正如預(yù)期的那樣，在沒有爭用的情況下，結(jié)果幾乎相同。 JIT將優(yōu)化鎖定并進(jìn)行同步。

在較低的百分位數(shù)中，使用Lock進(jìn)行爭用要快一些，但實(shí)際上并沒有太多。 因此，即使有許多較小的垃圾回收，它們似乎也沒有顯著降低鎖的速度。 如果有的話，鎖定總體上會(huì)稍微快一點(diǎn)。

這些是為協(xié)調(diào)省略而調(diào)整的結(jié)果。

這些數(shù)字當(dāng)然更高，因?yàn)樗鼈冊(cè)试S引起真正的延遲。

同樣，鎖和同步也沒有爭用，它們的作用相同–在那里沒有很大的驚喜。

通過爭用，直到第99個(gè)百分位，我們現(xiàn)在看到的同步鎖定性能提高了10倍。 之后，時(shí)間幾乎相同。

我可以推測，與同步相比，gc集合的影響（介于300-1200微秒之間）是導(dǎo)致鎖緩慢的原因。 尤其是因?yàn)樗俣认陆祪H出現(xiàn)到第99個(gè)百分位時(shí)才可見-在此之后，延遲可能會(huì)降到硬件和操作系統(tǒng)上。 但是，這只是我的推測，無需進(jìn)一步調(diào)查。

結(jié)論

這篇文章的收獲更多是關(guān)于衡量和分析延遲的過程。 有趣的是， Lock在競爭時(shí)進(jìn)行分配，但在現(xiàn)實(shí)世界中不太可能產(chǎn)生任何實(shí)際變化

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

mac 大寫鎖定延遲

總結(jié)

以上是生活随笔為你收集整理的mac 大写锁定延迟_延迟分析中的案例研究：锁定与同步的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。