并發編程之死鎖解析

yy736044583 發布于2019-08-15 17:45 / 1776人閱讀

摘要：如何檢測死鎖由于死鎖極難通過人工的方式查出來，因此提供了命令來檢測某個進程中心線程的情況，并排查有沒有死鎖。線程持有的鎖，等待的鎖。避免出現死鎖，如果出現了死鎖，則可以使用命令查看線程是否有死鎖。

前言

在 Java 的并發編程中，有一個問題需要特別注意，那就是死鎖，如果發生了死鎖，基本就是重啟，而重啟將會丟失運行中的數據。所以，了解死鎖的形成并排查死鎖到預防死鎖成了一個重要的問題。

我們了解任何一個事情的步驟是：what，how，why，why not。

1. 什么是死鎖？

我們還是直接寫一段代碼來看看：

package hello;

public class DeadLock {

  public static void main(String[] args) {

    new Thread(() -> {
      try {
         new DeadLock().resource1();
      } catch (InterruptedException e) {
      }
    }
    ).start();

    new Thread(() -> {
      try {
         new DeadLock().resource2();
      } catch (InterruptedException e) {
      }
    }
    ).start();
  }

  void resource1() throws InterruptedException {

    synchronized ("resource1") {
      System.out.println("獲取資源1");
       // 等待 1 秒讓另一個線程拿到鎖
      Thread.sleep(1000);
      resource2();
    }


  }

  void resource2() throws InterruptedException {
    synchronized ("resource2") {
      System.out.println("獲取資源2");
      // 等待 1 秒讓另一個線程拿到鎖
      Thread.sleep(1000);
      resource1();
    }
  }
}

上面的代碼中，我們啟用了兩個線程，分別搶占2個資源，但這兩個資源又分別被不同的對象（字符串）鎖住了。當第一個線程調用 resource1 方法，進入同步塊，拿到鎖，并等待 1 秒鐘讓另一個線程進入 resource2 同步塊，當第二個線程進入同步塊后，注意：此時，拿著 resourec1 鎖的線程企圖拿到 resource2 的鎖，但這個時候，拿著 resource2 的線程也想去拿 resource1 的鎖。于是就出現了互相僵持的情況，誰也無法拿到對方的鎖，整個系統就卡死了。

這種情況就是死鎖。

像我們現在寫的代碼是自己故意造出來的死鎖，我們能夠發現，那如果是線上環境怎么辦，假如我們的系統卡死了，我們怎么知道到底是哪一段代碼出現了問題，有沒有可能使死鎖的問題。也就是如何檢測死鎖。

2. 如何檢測死鎖？

由于死鎖極難通過人工的方式查出來，因此JDK 提供了命令來檢測某個java進程中心線程的情況，并排查有沒有死鎖。上面命令呢？ jps , 用來查看java 程序的進程號，當然在 Linux 中也可以通過別的方式獲取， jstack 進程號命令則可以答應對應進程的棧信息，并找到死鎖。

我們就剛剛的程序，在 windows 上使用該命令。

C:Usersstateis0>jps
11060
2084 Launcher
10712 RemoteMavenServer
18040 Jps
11820 DeadLock





C:Usersstateis0>jstack 11820
2017-12-29 18:52:38
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode):

"DestroyJavaVM" #11 prio=5 os_prio=0 tid=0x051fe800 nid=0x1e0c waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #10 prio=5 os_prio=0 tid=0x18777800 nid=0x5664 waiting for monitor entry [0x18e0f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at hello.DeadLock.resource1(DeadLock.java:31)
        - waiting to lock <0x07415a50> (a java.lang.String)
        at hello.DeadLock.resource2(DeadLock.java:43)
        - locked <0x0742bd18> (a java.lang.String)
        at hello.DeadLock.lambda$main$1(DeadLock.java:20)
        at hello.DeadLock$$Lambda$2/4983748.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #9 prio=5 os_prio=0 tid=0x18776c00 nid=0x4dc4 waiting for monitor entry [0x18d7f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at hello.DeadLock.resource2(DeadLock.java:41)
        - waiting to lock <0x0742bd18> (a java.lang.String)
        at hello.DeadLock.resource1(DeadLock.java:33)
        - locked <0x07415a50> (a java.lang.String)
        at hello.DeadLock.lambda$main$0(DeadLock.java:11)
        at hello.DeadLock$$Lambda$1/5592464.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #8 daemon prio=9 os_prio=0 tid=0x186e4c00 nid=0x172c runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x186af000 nid=0x53f8 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x1861e800 nid=0x3928 runnable [0x18b3f000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x07861da0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x07861da0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x179c0800 nid=0x40a0 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x17985c00 nid=0x5004 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x17972400 nid=0x41a8 in Object.wait() [0x17cff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0ca1b830> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0ca1b830> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x17960000 nid=0x4ef0 in Object.wait() [0x17c6f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0ca1b9d0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x0ca1b9d0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x1795a800 nid=0x3f54 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x18739400 nid=0x4a14 waiting on condition

JNI global references: 229

// 找到一個死鎖
Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x17978de4 (object 0x07415a50, a java.lang.String),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x1797a974 (object 0x0742bd18, a java.lang.String),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at hello.DeadLock.resource1(DeadLock.java:31)
         // 等待 0x07415a50 鎖
        - waiting to lock <0x07415a50> (a java.lang.String)
        at hello.DeadLock.resource2(DeadLock.java:43)
        // 持有 0x0742bd18
        - locked <0x0742bd18> (a java.lang.String)
        at hello.DeadLock.lambda$main$1(DeadLock.java:20)
        at hello.DeadLock$$Lambda$2/4983748.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at hello.DeadLock.resource2(DeadLock.java:41)
        // 等待 0x0742bd18 鎖
        - waiting to lock <0x0742bd18> (a java.lang.String)
        at hello.DeadLock.resource1(DeadLock.java:33)
        // 持有 0x07415a50
        - locked <0x07415a50> (a java.lang.String)
        at hello.DeadLock.lambda$main$0(DeadLock.java:11)
        at hello.DeadLock$$Lambda$1/5592464.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

// 發現了一個死鎖
Found 1 deadlock.


C:Usersstateis0>

Thread-1  waiting to lock <0x07415a50>      locked <0x0742bd18>
Thread-0  waiting to lock <0x0742bd18>       locked <0x07415a50>

我們首先使用 jps 命令找到 java 進程號，然后使用 jstack 進程號 打印進程棧的信息，其中，在最后的部分，jstack 告訴我們，他找到了一個死鎖，其中又詳細的信息：Thread-1 線程（這里我們沒有給線程其合適的名字，如果在線上，給線程起一個合適的名字將更有利于排查）持有 String 類型的編號為 0x07415a50 的鎖，等待編號為 0x07415a50 的鎖，但這個鎖由 Thread-0 持有，于此同時，Thread-0 和 Thread-1 相反。Thread-0 線程持有 0x07415a50 的鎖，等待 0x07415a50 的鎖。我們的注釋里也寫上了。

那么發生了死鎖，該怎么辦呢？最簡單的辦法就是重啟，重啟之后，對 jstack 中打印的堆棧信息中的代碼進行修改。重新發布。當然還有一些高級策略，比如讓進程回滾到死鎖前的狀態，然后讓他們順序進入同步塊。

3. 死鎖有哪些形成的原因

一般來說，要出現死鎖問題需要滿足以下條件：

互斥條件：一個資源每次只能被一個線程使用。

請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。

不剝奪條件：進程已獲得的資源，在未使用完之前，不能強行剝奪。

循環等待條件：若干進程之間形成一種頭尾相接的循環等待資源關系。

死鎖是由四個必要條件導致的，所以一般來說，只要破壞這四個必要條件中的一個條件，死鎖情況就應該不會發生。

如果想要打破互斥條件，我們需要允許進程同時訪問某些資源，這種方法受制于實際場景，不太容易實現條件；

打破不可搶占條件，這樣需要允許進程強行從占有者那里奪取某些資源，或者簡單一點理解，占有資源的進程不能再申請占有其他資源，必須釋放手上的資源之后才能發起申請，這個其實也很難找到適用場景；

進程在運行前申請得到所有的資源，否則該進程不能進入準備執行狀態。這個方法看似有點用處，但是它的缺點是可能導致資源利用率和進程并發性降低；

避免出現資源申請環路，即對資源事先分類編號，按號分配。這種方式可以有效提高資源的利用率和系統吞吐量，但是增加了系統開銷，增大了進程對資源的占用時間。

4 總結

并發編程中的坑很多，尤其死鎖，造成的問題基本只能靠重啟來解決，如果遇到了數據保存在內存中但沒有持久化的話，那么重啟將出現很大的問題。因此我們在用鎖的時候，一定要小心。避免出現死鎖，如果出現了死鎖，則可以使用 jstack 命令查看線程是否有死鎖。用以排查問題。

總之并發的坑很多，樓主以后將會多多分析。

good luck ！！！！

GPU云服務器云服務器易語言編程之并發編程編程之道中英文 Python并發編程

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/69426.html

我的阿里之路+Java面經考點

摘要：我的是忙碌的一年，從年初備戰實習春招，年三十都在死磕源碼，三月份經歷了阿里五次面試，四月順利收到實習。因為我心理很清楚，我的目標是阿里。所以在收到阿里之后的那晚，我重新規劃了接下來的學習計劃，將我的短期目標更新成拿下阿里轉正。我的2017是忙碌的一年，從年初備戰實習春招，年三十都在死磕JDK源碼，三月份經歷了阿里五次面試，四月順利收到實習offer。然后五月懷著忐忑的心情開始了螞蟻金...

姘擱『 2019-08-15 14:42 評論0 收藏0
并發編程之并發編程的挑戰

摘要：關于并發編程，其目的就是為了讓程序運行得更快，但是，并不是啟動更多的線程就能讓程序更大限度的并發執行。對于軟件資源限制考慮使用資源池將資源復用，例如數據庫連接池等資源限制情況下進行并發編程根據不同的資源限制調整程序的并發度。關于并發編程，其目的就是為了讓程序運行得更快，但是，并不是啟動更多的線程就能讓程序更大限度的并發執行。有哪些影響并發編程的因素呢？一、文章導圖 showImg(...

LeanCloud 2019-08-19 10:24 評論0 收藏0
多線程編程完全指南

摘要：在這個范圍廣大的并發技術領域當中多線程編程可以說是基礎和核心，大多數抽象并發問題的構思與解決都是基于多線程模型來進行的。一般來說，多線程程序會面臨三類問題正確性問題效率問題死鎖問題。多線程編程或者說范圍更大的并發編程是一種非常復雜且容易出錯的編程方式，但是我們為什么還要冒著風險艱辛地學習各種多線程編程技術、解決各種并發問題呢？因為并發是整個分布式集群的基礎，通過分布式集群不僅可以大...

mengera88 2019-08-19 11:47 評論0 收藏0
Javag工程師成神之路（2019正式版）

摘要：結構型模式適配器模式橋接模式裝飾模式組合模式外觀模式享元模式代理模式。行為型模式模版方法模式命令模式迭代器模式觀察者模式中介者模式備忘錄模式解釋器模式模式狀態模式策略模式職責鏈模式責任鏈模式訪問者模式。主要版本更新時間備注 v1.0 2015-08-01 首次發布 v1.1 2018-03-12 增加新技術知識、完善知識體系 v2.0 2019-02-19 結構...

Olivia 2019-08-16 15:14 評論0 收藏0
Java多線程學習（七）并發編程中一些問題

摘要：因為多線程競爭鎖時會引起上下文切換。減少線程的使用。舉個例子如果說服務器的帶寬只有，某個資源的下載速度是，系統啟動個線程下載該資源并不會導致下載速度編程，所以在并發編程時，需要考慮這些資源的限制。最近私下做一項目，一bug幾日未解決，總惶恐。一日頓悟，bug不可怕，怕的是項目不存在bug,與其懼怕，何不與其剛正面。系列文章傳送門: Java多線程學習（一）Java多線程入門 Jav...

yimo 2019-08-15 15:20 評論0 收藏0