java 分析java死鎖

您是否曾經(jīng)使用過java.util.concurrent.CountDownLatch ？

這是在兩個(gè)或多個(gè)線程之間實(shí)現(xiàn)同步的非常方便的類，在該類中，一個(gè)或多個(gè)線程可以等待，直到在其他線程中執(zhí)行的一組操作完成為止（請(qǐng)參閱javadoc和此文章 ）。 在合適的情況下， CountDownLatch可以節(jié)省您的時(shí)間，您必須了解此類。

與往常一樣，如果代碼不好，線程同步會(huì)引發(fā)死鎖。 并且由于并發(fā)用例可能非常復(fù)雜，因此開發(fā)人員必須非常小心。 在這里我不會(huì)描述復(fù)雜的并發(fā)問題，但是如果您不小心使用CountDownLatch ，可能會(huì)遇到一個(gè)簡(jiǎn)單的問題。

假設(shè)您有2個(gè)線程（線程1和線程2）共享一個(gè)java.util.concurrent.ArrayBlockingQueue，并且您想使用CountDownLatch對(duì)其進(jìn)行同步。 檢查以下簡(jiǎn)單示例：

package gr.qiozas.simple.threads.countdownlatch;import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.CountDownLatch;public class DeadlockCaseCDL {public static void main(String[] args) throws InterruptedException {CountDownLatch c = new CountDownLatch(1);ArrayBlockingQueue b = new ArrayBlockingQueue(1);new Thread(new T1(c, b)).start();new Thread(new T2(c, b)).start();}private static class T1 implements Runnable {private CountDownLatch c;private ArrayBlockingQueue b;private T1(CountDownLatch c, ArrayBlockingQueue b) {this.c = c; this.b = b;}public void run() {try {b.put(234);b.put(654);doWork(T1.class);c.countDown();doWork(T1.class);} catch (InterruptedException ex) {}}}private static class T2 implements Runnable {private CountDownLatch c;private ArrayBlockingQueue b;private T2(CountDownLatch c, ArrayBlockingQueue b) {this.c = c; this.b = b;}public void run() {try {doWork(T2.class);c.await();doWork(T2.class);System.out.println("I just dequeue "+b.take());System.out.println("I just dequeue "+b.take());} catch (InterruptedException ex) {}}}private static void doWork(Class classz) {System.out.println(classz.getName()+" do the work");} }

您在上面看到的是，主線程創(chuàng)建了一個(gè)計(jì)數(shù)為1的CountDownLatch。 和一個(gè)容量為“ 1”的ArrayBlockingQueue 然后生成“ 2個(gè)線程”。 ArrayBlockingQueue將用于實(shí)際的“工作”（入隊(duì)和出隊(duì)），而CountDownLatch將用于同步線程（入隊(duì)必須在出隊(duì)前完成）。

線程1使2條消息入隊(duì)，線程2希望使它們出隊(duì)，但僅在線程1使兩條消息入隊(duì)之后。 此同步由CountDownLatch保證。 您認(rèn)為此代碼可以嗎？ 不，這不是造成死鎖的原因！

如果仔細(xì)看第10行，您將看到我初始化ArrayBlockingQueue的容量等于“ 1”。 但是線程1要排隊(duì)2條消息，然后釋放（CountDownLatch）的鎖，以便隨后被線程2占用。 容量“ 1？ 隊(duì)列中的1個(gè)線程阻塞Thread-1，直到另一個(gè)線程將一個(gè)消息從隊(duì)列中出隊(duì)，然后再次嘗試使第二條消息入隊(duì)。 不幸的是，只有線程2使消息從隊(duì)列中出隊(duì)，但是由于線程1擁有CountDownLatch鎖，因此線程2無法使任何消息出隊(duì)，因此它被阻塞了。 因此，由于兩個(gè)線程都被阻塞（等待獲取不同的鎖），我們確實(shí)有一個(gè)死鎖 。 線程1等待ArrayBlockingQueue鎖定，而線程2等待CountDownLatch鎖定（您也可以在下面的相關(guān)線程轉(zhuǎn)儲(chǔ)中看到它）。

如果我們?cè)黾雨?duì)列的容量，那么此代碼將毫無問題地運(yùn)行，但這不是本文的重點(diǎn)。 您需要了解的是，必須謹(jǐn)慎使用CountDownLatch，以避免此類危險(xiǎn)情況。 您必須了解您的類的功能情況，向團(tuán)隊(duì)的其他開發(fā)人員詳細(xì)說明該功能，編寫有用的javadoc，并始終編寫在極端情況下（不僅對(duì)于快樂路徑而言）都非常可靠的代碼。

您可能需要幫助的另一點(diǎn)是，現(xiàn)代JVM無法檢測(cè)到此死鎖。 試試吧。

您可能知道，現(xiàn)代JVM（Hotspot和JRockit）都能夠檢測(cè)到簡(jiǎn)單的死鎖，并在線程轉(zhuǎn)儲(chǔ)中報(bào)告它們。 請(qǐng)參閱從Hotspot JVM檢測(cè)到的簡(jiǎn)單死鎖示例：

Found one Java-level deadlock: ============================= "Thread-6": waiting to lock monitor 0x00a891ec (object 0x06c616e0, a java.lang.String), which is held by "Thread-9" "Thread-9": waiting to lock monitor 0x00a8950c (object 0x06c61708, a java.lang.String), which is held by "Thread-6"

您可以嘗試DeadlockCaseCDL并獲得線程轉(zhuǎn)儲(chǔ)（在GNU / Linux上僅運(yùn)行“ kill -3 ?jvm_pid?”）。 您會(huì)看到線程轉(zhuǎn)儲(chǔ)看起來很正常，并且JVM未檢測(cè)到死鎖，但是您處于死鎖狀態(tài)！！！ 因此，請(qǐng)注意，JVM無法檢測(cè)到這種死鎖。

從我的本地執(zhí)行中檢查以下線程轉(zhuǎn)儲(chǔ)示例：

Full thread dump Java HotSpot(TM) Server VM (17.1-b03 mixed mode):"DestroyJavaVM" prio=10 tid=0x0946e800 nid=0x5382 waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"Thread-1" prio=10 tid=0x094b1400 nid=0x5393 waiting on condition [0x7c79a000]java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for (a java.util.concurrent.CountDownLatch$Sync)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)at gr.qiozas.simple.threads.countdownlatch.DeadlockCaseCDL$T2.run(DeadlockCaseCDL.java:50)at java.lang.Thread.run(Thread.java:662)"Thread-0" prio=10 tid=0x094afc00 nid=0x5392 waiting on condition [0x7c7eb000]java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:252)at gr.qiozas.simple.threads.countdownlatch.DeadlockCaseCDL$T1.run(DeadlockCaseCDL.java:29)at java.lang.Thread.run(Thread.java:662)"Low Memory Detector" daemon prio=10 tid=0x0947f800 nid=0x5390 runnable [0x00000000]java.lang.Thread.State: RUNNABLE"CompilerThread1" daemon prio=10 tid=0x7cfa9000 nid=0x538f waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"CompilerThread0" daemon prio=10 tid=0x7cfa7000 nid=0x538e waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"Signal Dispatcher" daemon prio=10 tid=0x7cfa5800 nid=0x538d waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"Finalizer" daemon prio=10 tid=0x7cf96000 nid=0x538c in Object.wait() [0x7cd15000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)- locked (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)"Reference Handler" daemon prio=10 tid=0x7cf94800 nid=0x538b in Object.wait() [0x7cd66000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:485)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)- locked (a java.lang.ref.Reference$Lock)"VM Thread" prio=10 tid=0x7cf92000 nid=0x538a runnable"GC task thread#0 (ParallelGC)" prio=10 tid=0x09475c00 nid=0x5383 runnable"GC task thread#1 (ParallelGC)" prio=10 tid=0x09477000 nid=0x5384 runnable"GC task thread#2 (ParallelGC)" prio=10 tid=0x09478800 nid=0x5385 runnable"GC task thread#3 (ParallelGC)" prio=10 tid=0x0947a000 nid=0x5387 runnable"VM Periodic Task Thread" prio=10 tid=0x09489800 nid=0x5391 waiting on conditionJNI global references: 854HeapPSYoungGen total 14976K, used 1029K [0xa2dd0000, 0xa3e80000, 0xb39d0000)eden space 12864K, 8% used [0xa2dd0000,0xa2ed1530,0xa3a60000)from space 2112K, 0% used [0xa3c70000,0xa3c70000,0xa3e80000)to space 2112K, 0% used [0xa3a60000,0xa3a60000,0xa3c70000)PSOldGen total 34304K, used 0K [0x815d0000, 0x83750000, 0xa2dd0000)object space 34304K, 0% used [0x815d0000,0x815d0000,0x83750000)PSPermGen total 16384K, used 1739K [0x7d5d0000, 0x7e5d0000, 0x815d0000)object space 16384K, 10% used [0x7d5d0000,0x7d782e90,0x7e5d0000)

參考： 有益的CountDownLatch和我們的JCG合作伙伴 Adrianos Dadis 遇到的棘手的Java僵局 ，位于“ Java，集成和源代碼的優(yōu)點(diǎn)”博客上 。

相關(guān)文章 ：

• Java并發(fā)教程– CountDownLatch
• 并發(fā)優(yōu)化–減少鎖粒度
• Java內(nèi)存模型-快速概述和注意事項(xiàng)
• Java并發(fā)教程–線程池
• Java并發(fā)教程–信號(hào)量
• Java教程和Android教程列表

翻譯自: https://www.javacodegeeks.com/2011/11/beneficial-countdownlatch-and-tricky.html

java 分析java死鎖

總結(jié)

以上是生活随笔為你收集整理的java 分析java死锁_有益的CountDownLatch和棘手的Java死锁的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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