2. 程式人生 > >Java死鎖以及命令檢測

Java死鎖以及命令檢測

阿新 • • 發佈：2018-07-16
阻塞 one found font pat rgs strong thread ron

Java每個對象都有一把鎖，當前進程使用對象鎖1，沒有釋放該鎖，又想要去獲取另一把對象鎖2，而對象鎖2被另外一個線程持有，沒有釋放，這就很容易出現死鎖

1.死鎖實例

public class DeadLockTest {

	private static Object object1 = new Object();
	private static Object object2 = new Object();

	public static void main(String[] args) {
		
		new Thread(new Runnable() {
			
			@Override
			public void run() {
				synchronized (object1) {
					System.out.println("線程1獲取object1鎖...");
					try {
						Thread.sleep(1000);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
					synchronized (object2) {
						System.out.println("線程1獲取object2鎖...");
					}
				}
			}
		}).start();
		
		new Thread(new Runnable() {
			
			@Override
			public void run() {
				synchronized (object2) {
					System.out.println("線程2獲取object2鎖...");
					synchronized (object1) {
						System.out.println("線程2獲取object1鎖...");
					}
				}
			}
		}).start();
		
		System.out.println("main 線程執行完畢...");
	}
}

分析：線程1持有object1的鎖，同時又想去獲取object2的鎖，而此時線程2又持有object2的鎖沒有釋放，又想去獲取object1的鎖，這就造成了死鎖。

2.通過命令查看死鎖

前提：進入jdk的bin目錄下

2.1 jps

jps命令查看Java相關進程

技術分享圖片

2.2 jstack

jstack：查看分析具體的進程執行情況

運行上面的程序，執行jps命令，發現上面代碼的進程號為14888

然後執行jstack -l pid（進程號）

C:\Program Files\Java\jdk1.8.0_51\bin>jstack -l 14144
2018-07-15 23:44:43
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000004dd3800 nid=0x3808 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001c1a1000 nid=0x2af4 waiting for monitor entry [0x000000001ce2f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.liu.demo.test.thread.DeadLockTest$2.run(DeadLockTest.java:36)
- waiting to lock <0x00000000d60ba308> (a java.lang.Object)
- locked <0x00000000d60ba318> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)

Locked ownable synchronizers:
- None

"Thread-0" #11 prio=5 os_prio=0 tid=0x000000001c1a0000 nid=0x6d0 waiting for monitor entry [0x000000001cd2f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.liu.demo.test.thread.DeadLockTest$1.run(DeadLockTest.java:23)
- waiting to lock <0x00000000d60ba318> (a java.lang.Object)
- locked <0x00000000d60ba308> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)

Locked ownable synchronizers:
- None

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001c0df000 nid=0x2c0c runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x000000001c0c7000 nid=0x41ac waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x000000001c0bf800 nid=0x27e8 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x000000001c0be000 nid=0x3728 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x000000001c0b9800 nid=0x2f08 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

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

Locked ownable synchronizers:
- None

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

Locked ownable synchronizers:
- None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000004ecc000 nid=0x798 in Object.wait() [0x000000001bf2f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000d5f06f58> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0x00000000d5f06f58> (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)

Locked ownable synchronizers:
- None

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000004ec5000 nid=0x43ec in Object.wait() [0x000000001be2f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000d5f06998> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
- locked <0x00000000d5f06998> (a java.lang.ref.Reference$Lock)

Locked ownable synchronizers:
- None

"VM Thread" os_prio=2 tid=0x0000000019f38000 nid=0x2f88 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000004de9800 nid=0x1324 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000004deb000 nid=0x1e24 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000004dec800 nid=0x1bb4 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000004dee000 nid=0x36c4 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000004df0800 nid=0x3838 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000004df2800 nid=0x1d2c runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000004df5800 nid=0x4214 runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000004df7000 nid=0x3018 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001c159000 nid=0x266c waiting on condition

JNI global references: 6


Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x0000000004eca3e8 (object 0x00000000d60ba308, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x0000000004ecb7d8 (object 0x00000000d60ba318, a java.lang.Object),
which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.liu.demo.test.thread.DeadLockTest$2.run(DeadLockTest.java:36)
- waiting to lock <0x00000000d60ba308> (a java.lang.Object)
- locked <0x00000000d60ba318> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
"Thread-0":
at com.liu.demo.test.thread.DeadLockTest$1.run(DeadLockTest.java:23)
- waiting to lock <0x00000000d60ba318> (a java.lang.Object)
- locked <0x00000000d60ba308> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

從上面的結果中可以看到，兩個線程都處於BLOCKED阻塞狀態，並且明確指出發現了一個死鎖；

Java死鎖以及命令檢測

相關推薦

Java死鎖以及命令檢測

阻塞 one found font pat rgs strong thread ron Java每個對象都有一把鎖，當前進程使用對象鎖1，沒有釋放該鎖，又想要去獲取另一把對象鎖2，而對象鎖2被另外一個線程持有，沒有釋放，這就很容易出現死鎖 1.死鎖實例 public cl

Java死鎖範例以及如何分析死鎖（轉載自ImportNew）

ofo index 對象 str wait 就會 moni ask 進入 本文由 ImportNew - 範琦琦 翻譯自 journaldev。歡迎加入翻譯小組。轉載請見文末要求。 死鎖是兩個甚至多個線程被永久阻塞時的一種運行局面，這種局面的生成伴隨著至少兩個線程和兩個或者

Java死鎖

允許 class err pub 完全 tac san 執行 rup 代碼如下： 1 package com.synchronizeddemo01; 2 3 class Zhangsan{ 4 public void say(){ 5

Java死鎖舉例

nbsp 產生 cep -a pack 存在 bsp trac code 死鎖： 在多線程競爭使用共享資源的情況下。就有可能出現死鎖的情況。比方，當一個線程等待還有一個線程所持有的鎖時。那個線程又可能在等待第一個線程所持有的鎖。此時。這兩個線程會陷入無休止

java死鎖問題

我們 告訴 tac image http 了解 src bsp 分享 一.先從定義上了解一下死鎖 二.從代碼角度上去解釋一下死鎖問題 三.上述程序就是出現了死鎖，我們來查看一下 1.命令如下 cmd>>jps(查看到了死鎖線程所在的類，前面是

Java 死鎖

ron func run blog pub read 同步 lock println /* 死鎖：常見情景之一：同步的嵌套。 */ class Test implements Runnable { private boolean flag;

一個JAVA死鎖的Demo

死鎖的條件肯定是兩個鎖以上時，才會 發生死鎖，以下Demo是模擬的兩個鎖，通過兩個執行緒分別呼叫兩個方法，這兩個方法加鎖的順序正好相反，從而造成兩個執行緒相互等待，互不釋放鎖 package com.threadDemo; public class DeadlockSam

java 死鎖處理方案

在我們開發中如果我們使用多執行緒併發執行並不能帶來很大的效率提升，我建議儘可能的少使用一些多執行緒，因為我們稍有不注意就可能帶來意想不到的結果。下面簡單看一下出現死鎖情況我們該怎麼處理呢？ 2.查詢到我們問題程序id,使用jstack 命令進行分析。 那麼我們遇到死鎖

Java死鎖程式碼示例

public class DeadLocak { private final Object left = new Object(); private final Object right = new Object(); public void le

多執行緒排查死鎖的命令

1、使用JVM自帶的命令 1）首先通過 jps 命令檢視需要檢視的Java程序的vmid，如圖，我們要檢視的程序ThreadState的vmid號是5132； C:\Users\Tom>jps 10716 Jps 6708 RemoteMavenServer 5132 ThreadSt

java-死鎖現象及解決方法

摘自：http://blog.csdn.net/joejames/article/details/37960873 所謂死鎖：是指兩個或兩個以上的程序在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀

Java 死鎖例子（註釋詳細）

為了測試java多執行緒死鎖 得到java多執行緒死鎖的直觀感覺，寫出以下測試程式碼。 public class DeadLock { public static String obj1 = "obj1"; public static String obj2 = "obj2";

java死鎖產生的原因

產生死鎖，至少有兩把鎖，多執行緒。一般是A執行緒獲取A鎖，B執行緒獲取了B鎖，這時A執行緒又要獲取B鎖，B執行緒又要獲取A鎖，從而導致死鎖，這個會出現程式碼不繼續執行了，可以用jconsole分析，哪個執行緒產生了死鎖。 1、程式至少有兩把鎖，相互鎖住。 public c

死鎖以及死鎖的避免方法

 一、要點提示  二、內容簡介   在計算機系統中有很多一次只能由一個程序使用的資源，如印表機，磁帶機，一個檔案的I節點等。在多道程式設計環境中，若干程序往往要共享這類資源，而且一個程序所需要的資源不止一個。這樣，就會出現若干程序競爭有限資源，又推進順序不當，從而構成無限期迴圈等待的

多執行緒死鎖以及解決方法

解決死鎖沒有簡單的方法，這是因為執行緒產生死鎖都各有各的原因，而且往往具有很高的負載。大多數軟體測試產生不了足夠多的負載，所以不可能暴露所有的執行緒錯誤。在這裡中，下面將討論開發過程常見的4類典型的死

一個簡單的Java死鎖示例

在實際程式設計中，要儘量避免出現死鎖的情況，但是讓你故意寫一個死鎖的程式時似乎也不太簡單（有公司會出這樣的面試題），以下是一個簡單的死鎖例子，程式說明都寫著類的註釋裡了，有點羅嗦，但是應該也還是表述清楚了的。 [code=java] /** * 一個簡單的死鎖類 *

Java死鎖的排查

先弄個死鎖的程式碼例子： public class DeadLock implements Runnable { private int flagCurrent = -1; private s

寫一個 java 死鎖玩玩

java 死鎖很容易遇到，睡不著 寫一個 死鎖 上程式碼 package cn.nokia.rso; public class DeadLock { private st

java死鎖示例及分析排查

       死鎖是指多個執行緒迴圈等待它方佔有的資源而無限期地僵持下去的局面。如有o1與o2兩個資源，執行緒t1持有o1後，如果再持有o2，就能正常完成操作，不巧，這時另一個執行緒t2已經持有o2,若再持有o1，則能完成操作，這樣就互相等對方持有的資源，產生死鎖。 一

一文學會Java死鎖和CPU 100% 問題的排查技巧

做一個積極的人 編碼、改bug、提升自己 我有一個樂園，面向程式設計，春暖花開 工欲善其事，必先利其器     00 本文簡介 作為一名搞技術的程式猿或者是攻城獅，想必你應該是對下面這兩個問題有所瞭解，說不定你在實際的工作或者面試就有遇到過： 第一個問題：Java死