线程基础（五）死锁

最新推荐文章于 2023-04-03 13:37:43 发布

踟蹰千年

最新推荐文章于 2023-04-03 13:37:43 发布

阅读量417

点赞数 2

分类专栏： # 并发多线程

本文链接：https://blog.csdn.net/baiyan3212/article/details/86512387

版权

并发多线程专栏收录该内容

15 篇文章 0 订阅

订阅专栏

死锁单独写一篇文章是因为这是一个很严重的、必须要引起重视的问题。这不是夸大死锁的风险，尽管锁被持有的时间通常很短，但是作为商业产品的应用程序每天可能要执行数十亿次获取锁->释放锁的操作，只要在这数十亿次操作中只要有一次发生了错误，就可能导致程序中发生死锁，并且即使通过压力测试也不可能找出所有潜在的死锁。

死锁的产生

当一个线程永远地持有一个锁，并且其他线程都尝试去获得这个锁时，那么它们将永远被阻塞，这个我们都知道。如果线程A持有锁L并且想获得锁M，线程B持有锁M并且想获得锁L，那么这两个线程将永远等待下去，这种情况就是最简单的死锁形式。

在数据库系统的设计中考虑了监测死锁以及从死锁中恢复，数据库如果监测到了一组事物发生了死锁时，将选择一个牺牲者并放弃这个事物。Java虚拟机解决死锁问题方面并没有数据库这么强大，当一组Java线程发生死锁时，这两个线程就永远不能再使用了，并且由于两个线程分别持有了两个锁，那么这两段同步代码/代码块也无法再运行了----除非终止并重启应用。

死锁是设计的BUG，问题比较隐晦。不过死锁造成的影响很少会立即显现出来，一个类可能发生死锁，并不意味着每次都会发生死锁，这只是表示有可能。当死锁出现时，往往是在最糟糕的情况----高负载的情况下。

/*
 * 死锁
 */
public class DeadLock {
	private Object lock1=new Object();
	private Object lock2=new Object();
	
	public void methodA(){
			try {
				synchronized(lock1){
					Thread.sleep(2000);	//休眠让当前线程占用锁1
					synchronized(lock2){
						System.out.println("lock1+lock2--end");
					}
				}
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
	}
	
	public void methodB(){
		try {
			synchronized(lock2){
				Thread.sleep(2000);	//休眠让当前线程占用锁2
				synchronized(lock1){
					System.out.println("lock2+lock1--end");
				}
			}
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
	
	public static void main(String[] args) {
		DeadLock dl = new DeadLock();
		Thread t1 = new Thread(new Runnable() {
			@Override
			public void run() {
				dl.methodA();
			}
		});
		
		Thread t2 = new Thread(new Runnable() {
			@Override
			public void run() {
				dl.methodB();
			}
		});
		t1.start();
		t2.start();
	}
}

如上代码，在运行时，两个线程会处于死锁状态，程序将无法停止，控制台中也无输出。因为线程1首先获取到锁1，然后休眠2秒后当他要获取锁2的时候，发现锁2已经被线程2获取到，此时他进入阻塞状态，同理线程2刚好和线程1相反，当他休眠2秒后，要获取锁1时发现锁1还被线程1所占用，于是他也开始等待，这样两个线程就一直互相等待。

这里的嵌套锁只是模拟死锁的情况，实际情况就是当前锁的对象被另一个锁获取（资源释放不一致导致的问题），双方都等待另一个线程放锁从而导致的死锁问题

定位死锁

1使用jps查询java虚拟机进程的Pid

2jstack打印堆栈。jstack打印内容的最后其实已经报告发现了一个死锁，但因为我们是分析死锁产生的原因，而不是直接得到这里有一个死锁的结论，所以别管它，就看前面的部分

1）"Thread-1"表示线程名称

（2）"prio=5"表示线程优先级

（3）"tid=0x000000000316e000 "表示线程Id

（4）nid=0x3528

线程对应的本地线程Id，这个重点说明下。因为Java线程是依附于Java虚拟机中的本地线程来运行的，实际上是本地线程在执行Java线程代码，只有本地线程才是真正的线程实体。Java代码中创建一个thread，虚拟机在运行期就会创建一个对应的本地线程，而这个本地线程才是真正的线程实体。Linux环境下可以使用"top -H -p JVM进程Id"来查看JVM进程下的本地线程（也被称作LWP）信息，注意这个本地线程是用十进制表示的，nid是用16进制表示的，转换一下就好了

（5）"java.lang.Thread.State：BLOCKED"表示线程的状态

解释完了每一部分的意思，看下Thread-1处于BLOCKED状态，Thread-0处于BLOCKED状态。对这两个线程分析一下：

（1）Thread-1获得了锁0x000000076b5b7830，在等待锁0x000000076b5b7820

（2）Thread-0获得了锁0x000000076b5b7820，在等待锁0x000000076b5b7830

由于两个线程都在等待获取对方持有的锁，所以就这么永久等待下去了。

下面是具体的堆栈信息

C:\Users\Administrator>jstack 7400
2019-01-16 18:27:48
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode):

"DestroyJavaVM" #12 prio=5 os_prio=0 tid=0x000000000316e000 nid=0x3528 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #11 prio=5 os_prio=0 tid=0x000000001e099000 nid=0x129c waiting for monitor entry [0x000000001ec8e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.xuxu.f_deadlock.DeadLock.methodB(DeadLock.java:28)
        - waiting to lock <0x000000076b5b7820> (a java.lang.Object)
        - locked <0x000000076b5b7830> (a java.lang.Object)
        at com.xuxu.f_deadlock.DeadLock$2.run(DeadLock.java:48)
        at java.lang.Thread.run(Thread.java:745)

"Thread-0" #10 prio=5 os_prio=0 tid=0x000000001e098000 nid=0x5c4 waiting for monitor entry [0x000000001eb8e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.xuxu.f_deadlock.DeadLock.methodA(DeadLock.java:15)
        - waiting to lock <0x000000076b5b7830> (a java.lang.Object)
        - locked <0x000000076b5b7820> (a java.lang.Object)
        at com.xuxu.f_deadlock.DeadLock$1.run(DeadLock.java:41)
        at java.lang.Thread.run(Thread.java:745)

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

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

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

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

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

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001cbca800 nid=0x2c24 in Object.wait() [0x000000001df2f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b508ee0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x000000076b508ee0> (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=0x00000000035c0800 nid=0x2a70 in Object.wait() [0x000000001de2f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b506b50> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x000000076b506b50> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x000000001cba8000 nid=0x2dcc runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00000000034e7000 nid=0x2768 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00000000034e8800 nid=0x3f68 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00000000034ea000 nid=0x4080 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00000000034eb800 nid=0xf20 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001e089000 nid=0x3acc waiting on condition

JNI global references: 6


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00000000035cb8b8 (object 0x000000076b5b7820, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00000000035c9028 (object 0x000000076b5b7830, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at com.xuxu.f_deadlock.DeadLock.methodB(DeadLock.java:28)
        - waiting to lock <0x000000076b5b7820> (a java.lang.Object)
        - locked <0x000000076b5b7830> (a java.lang.Object)
        at com.xuxu.f_deadlock.DeadLock$2.run(DeadLock.java:48)
        at java.lang.Thread.run(Thread.java:745)
"Thread-0":
        at com.xuxu.f_deadlock.DeadLock.methodA(DeadLock.java:15)
        - waiting to lock <0x000000076b5b7830> (a java.lang.Object)
        - locked <0x000000076b5b7820> (a java.lang.Object)
        at com.xuxu.f_deadlock.DeadLock$1.run(DeadLock.java:41)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

避免死锁的方式

既然可能产生死锁，那么接下来，讲一下如何避免死锁。

1、让程序每次至多只能获得一个锁。当然，在多线程环境下，这种情况通常并不现实

2、设计时考虑清楚锁的顺序，尽量减少嵌在的加锁交互数量

3、既然死锁的产生是两个线程无限等待对方持有的锁，那么只要等待时间有个上限不就好了。当然synchronized不具备这个功能，但是我们可以使用Lock类中的tryLock方法去尝试获取锁，这个方法可以指定一个超时时限，在等待超过该时限之后变回返回一个失败信息

踟蹰千年

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
线程基础（五）死锁

死锁单独写一篇文章是因为这是一个很严重的、必须要引起重视的问题。这不是夸大死锁的风险，尽管锁被持有的时间通常很短，但是作为商业产品的应用程序每天可能要执行数十亿次获取锁-&gt;释放锁的操作，只要在这数十亿次操作中只要有一次发生了错误，就可能导致程序中发生死锁，并且即使通过压力测试也不可能找出所有潜在的死锁。死锁的产生当一个线程永远地持有一个锁，并且其他线程都尝试去获得这个锁时，那么它们将...
复制链接

扫一扫