死鎖（Dead Lock）指的是兩個或兩個以上的運算單元（程序、線程或協程），都在等待對方停止執行，以取得系統資源，但是沒有一方提前退出，就稱為死鎖。
接下來，我們先來示範一下 Java 中最簡單的死鎖，我們建立兩個鎖和兩個線程，讓線程 1 先擁有鎖 A，然後在 1s 後嘗試擷取鎖 B，同時我們啟動線程 2，讓它先擁有鎖 B，然後在 1s 之後嘗試擷取鎖 A，這時就會出現互相等待對方釋放鎖的情況，進而造成死鎖的問題，具體代碼如下：
以上程式的執行結果如下：
從上述結果可以看出，線程 1 和線程 2 都在等待對方釋放鎖，這樣就造成了死鎖問題。
通過以上示例，我們可以得出結論，要産生死鎖需要滿足以下 4 個條件：
互斥條件：指運算單元（程序、線程或協程）對所配置設定到的資源具有排它性，也就是說在一段時間内某個鎖資源隻能被一個運算單元所占用。
請求和保持條件：指運算單元已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它運算單元占有，此時請求運算單元阻塞，但又對自己已獲得的其它資源保持不放。
不可剝奪條件：指運算單元已獲得的資源，在未使用完之前，不能被剝奪。
環路等待條件：指在發生死鎖時，必然存在運算單元和資源的環形鍊，即運算單元正在等待另一個運算單元占用的資源，而對方又在等待自己占用的資源，進而造成環路等待的情況。
隻有以上 4 個條件同時滿足，才會造成死鎖問題。
如果程式出現死鎖問題，可通過以下 4 種方案中的任意一種進行分析和排查。
我們在使用 jstack 之前，先要通過 jps 得到運作程式的程序 ID，使用方法如下：
“jps -l”可以查詢本機所有的 Java 程式，jps（Java Virtual Machine Process Status Tool）是 Java 提供的一個顯示目前所有 Java 程序 pid 的指令，适合在 linux/unix/windows 平台上簡單察看目前 Java 程序的一些簡單情況，“-l”用于輸出程序 pid 和運作程式完整路徑名（包名和類名）。
有了程序 ID（PID）之後，我們就可以使用“jstack -l PID”來發現死鎖問題了，如下圖所示：
jstack 用于生成 Java 虛拟機目前時刻的線程快照，“-l”表示長清單（long），列印關于鎖的附加資訊。
PS：可以使用 jstack -help 檢視更多指令使用說明。
使用 jconsole 需要打開 JDK 的 bin 目錄，找到 jconsole 并輕按兩下打開，如下圖所示：
然後選擇要調試的程式，如下圖所示：
之後點選連接配接進入，選擇“不安全的連接配接”進入監控首頁，如下圖所示：
之後切換到“線程”子產品，點選“檢測死鎖”按鈕，如下圖所示：
之後稍等片刻就會檢測出死鎖的相關資訊，如下圖所示：
jvisualvm 也在 JDK 的 bin 目錄中，同樣是輕按兩下打開：
稍等幾秒之後，jvisualvm 中就會出現本地的所有 Java 程式，如下圖所示：
輕按兩下選擇要調試的程式：
單機滑鼠進入“線程”子產品，如下圖所示：
從上圖可以看出，當我們切換到線程一欄之後就會直接顯示出死鎖資訊，之後點選“線程 Dump”生成死鎖的詳情資訊，如下圖所示：
jmc 是 Oracle Java Mission Control 的縮寫，是一個對 Java 程式進行管理、監控、概要分析和故障排查的工具套件。它也是在 JDK 的 bin 目錄中，同樣是輕按兩下啟動，如下圖所示：
jmc 首頁資訊如下：
之後選中要排查的程式，右鍵“啟動 JMX 控制台”檢視此程式的詳細内容，如下圖所示：
然後點選“線程”，勾中“死鎖檢測”就可以發現死鎖和死鎖的詳情資訊，如下圖所示：
死鎖是因為兩個或兩個以上的運算單元，都在等待對方停止執行，以取得系統資源，但沒有一方提前退出，于是就出現了死鎖。死鎖的排查工具總共有 4 種：
jstack
jconsole
jvisualvm
jmc
從易用性和性能方面來考慮，推薦使用 jconsole 或 jvisualvm 來排查死鎖。
blog.csdn.net/u010648555/article/details/80721815
cnblogs.com/cxuanBlog/p/13202898.html
zh.wikipedia.org/zh-hans/死鎖
線程的 4 種建立方法和使用詳解！
Java中使用者線程和守護線程差別這麼大？
深入了解線程池 ThreadPool
線程池的7種建立方式，強烈推薦你用它...
池化技術到達有多牛？看了線程和線程池的對比吓我一跳！
并發中的線程同步與鎖
synchronized 加鎖 this 和 class 的差別！
volatile 和 synchronized 的差別
輕量級鎖一定比重量級鎖快嗎？
這樣終止線程，竟然會導緻服務當機？
SimpleDateFormat線程不安全的5種解決方案！
ThreadLocal不好用？那是你沒用對！
ThreadLocal記憶體溢出代碼示範和原因分析！
Semaphore自白：限流器用我就對了！
CountDownLatch：别浪，等人齊再團！
CyclicBarrier：人齊了，司機就可以發車了！
synchronized 優化手段之鎖膨脹機制！
synchronized 中的 4 個優化，你知道幾個？
ReentrantLock 中的 4 個坑！
圖解：為什麼非公平鎖的性能更高？
關注公号「Java中文社群」檢視更多有意思、漲知識的 Java 并發文章。
關注下面二維碼，訂閱更多精彩内容。
關注公衆号（加好友）：
作者：
王磊的部落格
出處：
http://vipstone.cnblogs.com/