Java Deadlock Example and How to analyze deadlock situation

所謂死鎖：是指兩個或兩個以上的程序在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序稱為死鎖程序。由於資源佔用是互斥的，當某個程序提出申請資源後，使得有關程序在無外力協助下，永遠分配不到必需的資源而無法繼續執行，這就產生了一種特殊現象死鎖。

雖然程序在執行過程中，可能發生死鎖，但死鎖的發生也必須具備一定的條件，死鎖的發生必須具備以下四個必要條件。
1）互斥條件：指程序對所分配到的資源進行排它性使用，即在一段時間內某資源只由一個程序佔用。如果此時還有其它程序請求資源，則請求者只能等待，直至佔有資源的程序用畢釋放。
2）請求和保持條件：指程序已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它程序佔有，此時請求程序阻塞，但又對自己已獲得的其它資源保持不放。
3）不剝奪條件：指程序已獲得的資源，在未使用完之前，不能被剝奪，只能在使用完時由自己釋放。
4）環路等待條件：指在發生死鎖時，必然存在一個程序——資源的環形鏈，即程序集合{P0，P1，P2，···，Pn}中的P0正在等待一個P1佔用的資源；P1正在等待P2佔用的資源，……，Pn正在等待已被P0佔用的資源。
在系統中已經出現死鎖後，應該及時檢測到死鎖的發生，並採取適當的措施來解除死鎖。目前處理死鎖的方法可歸結為以下四種：

1) 預防死鎖
　　這是一種較簡單和直觀的事先預防的方法。方法是通過設定某些限制條件，去破壞產生死鎖的四個必要條件中的一個或者幾個，來預防發生死鎖。預防死鎖是一種較易實現的方法，已被廣泛使用。但是由於所施加的限制條件往往太嚴格，可能會導致系統資源利用率和系統吞吐量降低。

2) 避免死鎖
　　該方法同樣是屬於事先預防的策略，但它並不須事先採取各種限制措施去破壞產生死鎖的的四個必要條件，而是在資源的動態分配過程中，用某種方法去防止系統進入不安全狀態，從而避免發生死鎖。

3)檢測死鎖
　　這種方法並不須事先採取任何限制性措施，也不必檢查系統是否已經進入不安全區，此方法允許系統在執行過程中發生死鎖。但可通過系統所設定的檢測機構，及時地檢測出死鎖的發生，並精確地確定與死鎖有關的程序和資源，然後採取適當措施，從系統中將已發生的死鎖清除掉。

4)解除死鎖
　　這是與檢測死鎖相配套的一種措施。當檢測到系統中已發生死鎖時，須將程序從死鎖狀態中解脫出來。常用的實施方法是撤銷或掛起一些程序，以便回收一些資源，再將這些資源分配給已處於阻塞狀態的程序，使之轉為就緒狀態，以繼續執行。死鎖的檢測和解除措施，有可能使系統獲得較好的資源利用率和吞吐量，但在實現上難度也最大。


悲觀鎖：假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。
樂觀鎖：假設不會發生併發衝突，只在提交操作時檢查是否違反資料完整性。 樂觀鎖不能解決髒讀的問題

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

Deadlockis a programming situation where two or more threads are blocked forever, this situation arises with at least two threads and two or more resources.

例子：

package com.journaldev.threads;
 
public class ThreadDeadlock {
 
    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        Object obj2 = new Object();
        Object obj3 = new Object();
     
        Thread t1 = new Thread(new SyncThread(obj1, obj2), "t1");
        Thread t2 = new Thread(new SyncThread(obj2, obj3), "t2");
        Thread t3 = new Thread(new SyncThread(obj3, obj1), "t3");
         
        t1.start();
        Thread.sleep(5000);
        t2.start();
        Thread.sleep(5000);
        t3.start();
         
    }
 
}
 
class SyncThread implements Runnable{
    private Object obj1;
    private Object obj2;
 
    public SyncThread(Object o1, Object o2){
        this.obj1=o1;
        this.obj2=o2;
    }
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + " acquiring lock on "+obj1);
        synchronized (obj1) {
         System.out.println(name + " acquired lock on "+obj1);
         work();
         System.out.println(name + " acquiring lock on "+obj2);
         synchronized (obj2) {
            System.out.println(name + " acquired lock on "+obj2);
            work();
        }
         System.out.println(name + " released lock on "+obj2);
        }
        System.out.println(name + " released lock on "+obj1);
        System.out.println(name + " finished execution.");
    }
    private void work() {
        try {
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
 

結果：

t1 acquiring lock on [email protected]
t1 acquired lock on [email protected]
t2 acquiring lock on [email protected]
t2 acquired lock on [email protected]
t3 acquiring lock on [email protected]
t3 acquired lock on [email protected]
t1 acquiring lock on [email protected]
t2 acquiring lock on [email protected]
t3 acquiring lock on [email protected]

Analyze Deadlock 分析死鎖

To analyze a deadlock, we need to look at thejava thread dumpof the application, in last post I explained how we cangenerate thread dumpusing VisualVM profiler or using jstack utility.

【為了分析死鎖，我們需要用到"visualvm profile"應用，如果想看怎麼使用它，請先點連結下載:visualvm-1.3.8 ，然後點上面的連結看使用，這方面在國內介紹也比較比，可以自己百度.】

注：VisualVM 是一款免費的\集成了多個 JDK 命令列工具的視覺化工具,它能為您提供強大的分析能力,對 Java 應用程式做效能分析和調優。

以下是用"Java thread dump"分析的結果：

2012-12-27 19:08:34
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode):
 
"Attach Listener" daemon prio=5 tid=0x00007fb0a2814000 nid=0x4007 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"DestroyJavaVM" prio=5 tid=0x00007fb0a2801000 nid=0x1703 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"t3" prio=5 tid=0x00007fb0a204b000 nid=0x4d07 waiting for monitor entry [0x000000015d971000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f658> (a java.lang.Object)
    - locked <0x000000013df2f678> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
 
"t2" prio=5 tid=0x00007fb0a1073000 nid=0x4207 waiting for monitor entry [0x000000015d209000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f678> (a java.lang.Object)
    - locked <0x000000013df2f668> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
 
"t1" prio=5 tid=0x00007fb0a1072000 nid=0x5503 waiting for monitor entry [0x000000015d86e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f668> (a java.lang.Object)
    - locked <0x000000013df2f658> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
 
"Service Thread" daemon prio=5 tid=0x00007fb0a1038000 nid=0x5303 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"C2 CompilerThread1" daemon prio=5 tid=0x00007fb0a1037000 nid=0x5203 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"C2 CompilerThread0" daemon prio=5 tid=0x00007fb0a1016000 nid=0x5103 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"Signal Dispatcher" daemon prio=5 tid=0x00007fb0a4003000 nid=0x5003 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
 
"Finalizer" daemon prio=5 tid=0x00007fb0a4800000 nid=0x3f03 in Object.wait() [0x000000015d0c0000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000013de75798> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x000000013de75798> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
 
"Reference Handler" daemon prio=5 tid=0x00007fb0a4002000 nid=0x3e03 in Object.wait() [0x000000015cfbd000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000013de75320> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x000000013de75320> (a java.lang.ref.Reference$Lock)
 
"VM Thread" prio=5 tid=0x00007fb0a2049800 nid=0x3d03 runnable 
 
"GC task thread#0 (ParallelGC)" prio=5 tid=0x00007fb0a300d800 nid=0x3503 runnable 
 
"GC task thread#1 (ParallelGC)" prio=5 tid=0x00007fb0a2001800 nid=0x3603 runnable 
 
"GC task thread#2 (ParallelGC)" prio=5 tid=0x00007fb0a2003800 nid=0x3703 runnable 
 
"GC task thread#3 (ParallelGC)" prio=5 tid=0x00007fb0a2004000 nid=0x3803 runnable 
 
"GC task thread#4 (ParallelGC)" prio=5 tid=0x00007fb0a2005000 nid=0x3903 runnable 
 
"GC task thread#5 (ParallelGC)" prio=5 tid=0x00007fb0a2005800 nid=0x3a03 runnable 
 
"GC task thread#6 (ParallelGC)" prio=5 tid=0x00007fb0a2006000 nid=0x3b03 runnable 
 
"GC task thread#7 (ParallelGC)" prio=5 tid=0x00007fb0a2006800 nid=0x3c03 runnable 
 
"VM Periodic Task Thread" prio=5 tid=0x00007fb0a1015000 nid=0x5403 waiting on condition 
 
JNI global references: 114
 
 
Found one Java-level deadlock:
=============================
"t3":
  waiting to lock monitor 0x00007fb0a1074b08 (object 0x000000013df2f658, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x00007fb0a1010f08 (object 0x000000013df2f668, a java.lang.Object),
  which is held by "t2"
"t2":
  waiting to lock monitor 0x00007fb0a1012360 (object 0x000000013df2f678, a java.lang.Object),
  which is held by "t3"
 
Java stack information for the threads listed above:
===================================================
"t3":
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f658> (a java.lang.Object)
    - locked <0x000000013df2f678> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
"t1":
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f668> (a java.lang.Object)
    - locked <0x000000013df2f658> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
"t2":
    at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)
    - waiting to lock <0x000000013df2f678> (a java.lang.Object)
    - locked <0x000000013df2f668> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:722)
 
Found 1 deadlock.

The thread dump output clearly shows the deadlock situation and threads and resources involved causing deadlock situation.

For analyzing deadlock, we need to look out for the threads with state asBLOCKEDand then the resources it’swaiting to lock, every resource has a unique ID using which we can find which thread is already holding the lock on the object. For example Thread “t3″ is waiting to lock 0x000000013df2f658 but it’s already locked by thread “t1″.

Once we analyze the deadlock situation and found out the threads which are causing deadlock, we need to make code changes to avoid deadlock situation.

Avoid deadlock 避免死鎖

These are some of the guidelines using which we can avoid most of the deadlock situations.

• Avoid Nested Locks: This is the most common reason for deadlocks, avoid locking another resource if you already hold one. It’s almost impossible to get deadlock situation if you are working with only one object lock. For example, here is the another implementation of run() method without nested lock and program runs successfully without deadlock situation.
• 【粗譯： 避免巢狀死鎖：最是引起死鎖最常見的原因，如果你已經有鎖了避免鎖住另一個資源。如果你只工作在一個物件上的鎖，這是最不可能產生死鎖的了。例如，這裡有一個run方法的實現，在方法中，沒有巢狀鎖，程式會正常的執行而且不會產生死鎖。】
  

public void run() {
    String name = Thread.currentThread().getName();
    System.out.println(name + " acquiring lock on " + obj1);
    synchronized (obj1) {
        System.out.println(name + " acquired lock on " + obj1);
        work();
    }
    System.out.println(name + " released lock on " + obj1);
    System.out.println(name + " acquiring lock on " + obj2);
    synchronized (obj2) {
        System.out.println(name + " acquired lock on " + obj2);
        work();
    }
    System.out.println(name + " released lock on " + obj2);
 
    System.out.println(name + " finished execution.");
}

• Lock Only What is Required: You should acquire lock only on the resources you have to work on, for example in above program I am locking the complete Object resource but if we are only interested in one of it’s fields, then we should lock only that specific field not complete object. 【粗譯：只對需要的加鎖： 你應該在為，在工作中的唯一資源（可能是一個區域性，也可能是個物件，也可可能範圍更廣，但是那只是用到的資源；對於不需要的部分，不應該加鎖）上的去獲得鎖，例如上面的程式，我只在完成的物件資源上加鎖，但是如果我們只對某些部分感興趣，那麼我們應該只對那部分加鎖，而不是整個物件。】
  
• Avoid waiting indefinitely: You can get deadlock if two threads are waiting for each other to finish indefinitely usingthread join. If your thread has to wait for another thread to finish, it’s always best to use join with maximum time you want to wait for thread to finish.【避免無限期地等待：如果2個執行緒方法相互等待使用資源，那麼很容易產生死鎖。如果一個執行緒等待另一個執行緒完成，我們最好使用join()來等待另一個執行緒完成任務。】

If you liked this tutorial, make sure to check out otherjava threadtutorial.