死锁产生和解决

最新推荐文章于 2022-08-01 18:01:13 发布
最新推荐文章于 2022-08-01 18:01:13 发布
阅读量751 收藏
点赞数
分类专栏： 日常工作
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiaoxufox/article/details/60767606
版权

面试题，之前没在意，这里学习了解下。

死锁的产生

产生死锁的原因

  1. 因为系统资源不足，并发的请求就会有竞争，产生锁；
  2. 进程运行推进的顺序和速度不合适，例如事务性的流程，会多步骤执行，如推进顺序错乱，会产生死锁；
  3. 资源分配不当等，同1。

产生死锁的四个必要条件

  1. 互斥条件：一个资源每次只能被一个进程使用。
  2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
  3. 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
  4. 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
    这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

死锁的解除与预防

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。

解决方法：
1. 合理规划和分配系统资源；
2. 一次性获取所有锁；
3. 获取锁容许超时，获取某个锁失败，则释放已经持有的所有锁，重新获取锁；
4. 产生死锁，必然会有锁的获取和等待进程的环路，可以建立锁的获取列表和等待进程列表，然后单独的调度检测锁状态，检查是否有环路形成，如有，释放已经持有的锁，重新竞争，这种有点麻烦，不太常用。

死锁检测定位

这个是从参考1，那个哥们那里看到的，这里copy过来。

demo

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

/**
 * Created by Kevin on 11/4/16.
 */
class MultiThread implements Runnable{
    private Object o1;
    private Object o2;
    private int flag;

    public MultiThread(Object o1, Object o2, int flag) {
        this.o1 = o1;
        this.o2 = o2;
        this.flag = flag;
    }

    public void task1() throws InterruptedException{
        synchronized (o1){
            synchronized (o2){
                System.out.println(Thread.currentThread().getName());
            }
        }
    }

    public void task2() throws InterruptedException{
        synchronized (o2){
            Thread.yield();
            synchronized (o1) {
                System.out.println(Thread.currentThread().getName());
            }
        }
    }


    @Override
    public void run() {
        while (true) {
            try {
                if (this.flag == 1) {
                    this.task1();
                } else {
                    this.task2();
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

public class DeadLock {
    public static void main(String[] args){
        Object o1 = new Object();
        Object o2 = new Object();

        ExecutorService executorService = Executors.newFixedThreadPool(10);

        for (int flag = 0; flag < 2; flag++) {
            executorService.execute(new MultiThread(o1, o2, flag));
        }
    }
}

运行代码，你会发现控制台过一会儿就不动了，但是程序运行没有终止，下面用jstack看看到底啥问题。

$ jps
11523 Main
27894 AppMain
27912 Launcher
27933 Jps
12046 JConsole

看到pid=27894，用jstack查看一下进程27894：

$ jstack 27894
2016-11-07 14:59:55
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.101-b13 mixed mode):

"Attach Listener" #13 daemon prio=9 os_prio=0 tid=0x00007f5660001000 nid=0x6d3b runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"pool-1-thread-2" #11 prio=5 os_prio=0 tid=0x00007f5698156800 nid=0x6d07 waiting for monitor entry [0x00007f5684175000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at MultiThread.task1(DeadLock.java:21)
    - waiting to lock <0x00000000ec215b70> (a java.lang.Object)
    - locked <0x00000000ec215b60> (a java.lang.Object)
    at MultiThread.run(DeadLock.java:41)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

"pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x00007f5698155000 nid=0x6d06 waiting for monitor entry [0x00007f5684276000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at MultiThread.task2(DeadLock.java:30)
    - waiting to lock <0x00000000ec215b60> (a java.lang.Object)
    - locked <0x00000000ec215b70> (a java.lang.Object)
    at MultiThread.run(DeadLock.java:43)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

"Monitor Ctrl-Break" #9 daemon prio=5 os_prio=0 tid=0x00007f5698152800 nid=0x6d05 runnable [0x00007f5684377000]
   java.lang.Thread.State: RUNNABLE
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
    at java.net.ServerSocket.implAccept(ServerSocket.java:545)
    at java.net.ServerSocket.accept(ServerSocket.java:513)
    at com.intellij.rt.execution.application.AppMain$1.run(AppMain.java:90)
    at java.lang.Thread.run(Thread.java:745)

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

"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f56980bd000 nid=0x6d02 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f56980bb800 nid=0x6d01 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f56980b8800 nid=0x6d00 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f5698084000 nid=0x6cfe in Object.wait() [0x00007f5685682000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000ec188ee0> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
    - locked <0x00000000ec188ee0> (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=0 tid=0x00007f569807f800 nid=0x6cfd in Object.wait() [0x00007f5685783000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000ec186b50> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    - locked <0x00000000ec186b50> (a java.lang.ref.Reference$Lock)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=0 tid=0x00007f5698078000 nid=0x6cfc runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f569801f800 nid=0x6cf8 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f5698021000 nid=0x6cf9 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f5698023000 nid=0x6cfa runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f5698024800 nid=0x6cfb runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f56980dd000 nid=0x6d04 waiting on condition 

JNI global references: 15


Found one Java-level deadlock:
=============================
"pool-1-thread-2":
  waiting to lock monitor 0x00007f56680062c8 (object 0x00000000ec215b70, a java.lang.Object),
  which is held by "pool-1-thread-1"
"pool-1-thread-1":
  waiting to lock monitor 0x00007f5668004e28 (object 0x00000000ec215b60, a java.lang.Object),
  which is held by "pool-1-thread-2"

Java stack information for the threads listed above:
===================================================
"pool-1-thread-2":
    at MultiThread.task1(DeadLock.java:21)
    - waiting to lock <0x00000000ec215b70> (a java.lang.Object)
    - locked <0x00000000ec215b60> (a java.lang.Object)
    at MultiThread.run(DeadLock.java:41)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
"pool-1-thread-1":
    at MultiThread.task2(DeadLock.java:30)
    - waiting to lock <0x00000000ec215b60> (a java.lang.Object)
    - locked <0x00000000ec215b70> (a java.lang.Object)
    at MultiThread.run(DeadLock.java:43)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

发现java级别的deadlock，然后就去分析代码和场景吧！

数据库死锁解决

参考3种的内容。

  1. 尽量不要在一个事务中实现过于复杂的查询或更新操作。原因很简单，越是复杂的数据库操作，占用数据库资源的时间越长，引发死锁的可能性越大。

  2. 尽量不要在数据库事务中要求用户响应。原因同1，这也会导致事务长时间无法结束，浪费数据库资料。

  3. 死锁是由于并发访问数据库资源造成的，减少死锁就应该限制应用系统的并发访问量。我们应该合理设置后台服务的线程数，将大量数据的操作分解，分步骤，分阶段的执行。也应该避免在用户量大的时候大规模的进行后台数据库操作，应该将大规模的数据库操作放在用户量最少的时候进行。

  4. 尽可能以分区表或分区视图的方式拆分包含大量数据的表，将它们保存在不同的物量磁盘和文件组中。在访问数据时，可以分散访问保存在不同分区的数据，从而减少因为在大型表中放置锁而造成其它事务长时间等待的概率。

  5. 尽量避免使用占用很长的复杂查询,在条件允许的情况下应该尽量使用分页查询或缩小结果集的方式。因为复杂查询会长时间占用数据库资源，增加发生死锁的概率。

  6. 尽可能使用较低的隔离级别，如READ UNCOMMITTED，因为隔离级别低时，事务之间相互等待的情况会减少，这样每个事务都会尽可能快地完成数据库操作，然后释放其拥有的锁资源，这样就会降低出现锁等待或死锁的概率。当然，用户在设计数据库应用程序时，需要考虑如何解决事务中数据不一致的情况。

  7. 应该注意统一访问表的顺序，尽量避免有的事务先查询表A然后更新表B，而有的事务先查询表B再更新表A的情况。

  8. 如果一个事务中只进行读取数据的操作，则可以在该事务中使用快照(SNAPSHOT)隔离级别。因为在快照隔离级别中，数据库引擎不会阻塞其他事务对当前事务所占用资源的修改操作，当前事务会认为它所拥有的资源没有被修改过（实际上它所拥有的资源是一个快照）。这样就可以减少因为等待资源而产生死锁的情况。

参考

  1. http://blog.csdn.net/sinat_36246371/article/details/53066585 Java虚拟机工具之堆栈跟踪工具jstack检测死锁
  2. http://www.cnblogs.com/qianxun/p/3285739.html Linux下面多线程死锁问题的调试(gdb)
  3. http://www.lmwlove.com/ac/ID766 减少数据库死锁的8种方法
熊猫小牛牛
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
死锁检测 java_Java死锁以及命令检测
weixin_33662430的博客
02-21 595
Java每个对象都有一把锁，当前进程使用对象锁1，没有释放该锁，又想要去获取另一把对象锁2，而对象锁2被另外一个线程持有，没有释放，这就很容易出现死锁1.死锁实例public class DeadLockTest {private static Object object1 = new Object();private static Object object2 = new Object();pu...
死锁的产生及解决
m0_54202121的博客
04-23 446
文章目录死锁代码演示：验证是否是死锁：死锁产生的必要条件：什么时候会发生死锁：预防死锁①破坏互斥条件②破坏不剥夺条件③破坏请求和保持条件④破坏循环等待条件 就好比，小情侣们每天都要让对方说爱自己，究竟谁更爱谁就产生了死锁，哈哈哈哈哈。解决死锁的办法就是互相给对方戴green帽 死锁 两个或两个以上的进程因为争夺资源造成的一种等待的过程就是死锁，如果没有外力干涉，就不可能再进行下去。 代码演示： package com; public class DeadLock { //创建两个对象
jvm 性能监控命令
weixin_43931625的博客
07-20 373
jvm性能监控命令
jstack实战生产CPU爆高（五）
qq_35151346的博客
09-02 440
一、了解jstack 1.作用 查看java进程中线程信息 2.举例 jstack java进程pid "logback-2" #55 daemon prio=5 os_prio=31 tid=0x00007fa91a9af800 nid=0x3f07 waiting on condition [0x0000700002e5c000] java.lang.Thread.S...
交叉锁引起程序死锁
实践求真知
03-05 580
一 点睛 交叉锁不仅自己写的代码会出现，如果使用某个框架或者开源库，由于对源码 API 的不熟悉，很有可能也会引起死锁，这种情况出现死锁后，排查的困难则要高于前者，所以在使用框架或者开源库的时候要做到了如指掌。 二 代码 package concurrent; public class DeadLock { private final Object mutexRead = new Object(); private final Object mutexWrite = new Obj
Java 多线程&使用常见命令分析线程的信息——3
爱的叹息的专栏
05-24 2604
java代码：Thread5.java 创建5个线程,每个线程创建后睡眠500秒 package com.burns.callmainmethodmainthread; public class Thread5 { public static void main(String[] args) throws InterruptedException { for (int i = 0; i < 5; i++) { new Thread() {
死锁与并发问题解决
Bug君的博客
05-17 740
死锁与并发问题解决 一、死锁 1、死锁的必要条件 （1）互斥条件 （2）请求和保持条件 （3）不剥夺条件 （4）环路等待条件 2、最佳实践 （1）使用本地变量 （2）使用不可变类 （3）最小化锁的作用范围：S=1/(1-a+a/n) （4）使用线程池的Executor，而不是直接new Thread执行 （5）宁可使用同步也不要使用线程的wait和notify （6）使用BlockingQueue实现生产-消费模式 （7）使用并发集合而不是加了锁的同步集合 （8）使用Semaphore创建有界的访问 （9）
MSSQL死锁产生原因及解决方法
12-14
理解死锁的原因和解决方法对于确保数据库系统的正常运行至关重要。 **一、死锁的概念** 死锁是指在多进程环境中，两个或更多个进程在执行时因争夺资源而形成的一种僵局，每个进程都在等待其他进程释放其占用的资源...
MySQL死锁的产生原因以及解决方案
12-14
本文将探讨MySQL死锁的产生原因以及解决方案。 **死锁的产生原因** 1. **资源竞争与顺序依赖**：当两个事务A和B分别持有对方需要的资源，A等待B释放资源，B也在等待A释放资源，就会形成死锁。例如，事务A锁定表A后...
MySQL 死锁产生原因和解决办法
最新发布
07-27
所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁...所以解决死锁主要还是针对于最常用的InnoDB。
Java线程死锁实例及解决方法
08-25
二、死锁产生的必要条件 1. 互斥条件：线程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某资源仅为一个线程所占有。此时若有线程请求该资源，则请求线程只能等待。 2. 不剥夺条件：线程所获得的...
MSSQL产生死锁的根本原因及解决方法
09-10
【MSSQL死锁产生的原因及解决方法】 死锁是数据库管理系统...总结来说，理解死锁产生的原因和条件，并结合MSSQL Server提供的锁机制和管理工具，我们可以有效地预防和解决死锁问题，确保数据库系统的稳定和高效运行。
Android 系统（115）---死机问题分析
zhangbijun1230的专栏
06-21 4768
一、死机现象1. 死机/phong hang 定义当手机长时间无法再被用户控制操作时，我们称为死机或者hang 机。在这里我们强调长时间，如果是短时间，我们归结为Perfomance 问题，即性能问题.2. 死机表现* 用户操作手机无任何响应, 如触摸屏幕，按键操作等.* 手机屏幕黑屏, 无法点亮屏幕.* 手机界面显示内容和用户输入风马牛不相及.二、死机可能原因1. 系统简图当用户对手机进行操作时...
Java内存泄漏分析系列之五：常见的Thread Dump日志案例分析
weixin_30505485的博客
03-14 465
原文地址：http://www.javatang.com 症状及解决方案 下面列出几种常见的症状即对应的解决方案： CPU占用率很高，响应很慢 按照《Java内存泄漏分析系列之一：使用jstack定位线程堆栈信息》中所说的方法，先找到占用CPU的进程，然后再定位到对应的线程，最后分析出对应的堆栈信息。在同一时间多次使用上述的方法，然后进行对比分析，从代码中找到问题所在的原因。如果...
死锁分析及避免死锁
程序员小金的博客
09-17 414
什么是死锁 死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 产生死锁 下面我们看一个简单的demo public class DeadLockDemo { public static void main(String[] args) { for (int i = 1; i <= 100000; i++) {
Java线程死锁以及问题定位
weixin_38296425的博客
08-08 3012
死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够碍到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。 产生死锁主要原因: 系统资源不足 进程运行推进的顺序不合适 资源分配不当 发生死锁的四个条件： 互斥条件，线程使用的资源至少有一个不能共享的。 至少有一个线程必须持有一个资源且正在等待获取一个当前被别的线程持有的资源。 资源不能被抢占。 循环等待。 如何解决死锁问.
[Java故障排除指南- JDK11-学习笔记]-5-线程堆栈与死锁问题检测
宋小生-中间件
05-10 672
5-线程堆栈与死锁问题检测 线程堆栈分析 在程序运行时我们想要查看程序的执行状态,可以通过进程的线程堆栈信息来分析进程的健康状态,如果获取到一个运行中的Java进程的线程堆栈呢,我们可以用这几个命令: 先查询Java进程id jps -l 通过Java进程id查询当前进程的堆栈信息 jstack -l 17389 如下是实际操作中的一个案例 ➜ ~ jps -l 288 org.jetbrains.jps.cmdline.Launcher 66245 1670 sun.tools.jps.Jps
【安卓源码阅读】简单追溯几个内存回收的守护线程
qq_23542165的博客
08-01 1203
其实在进行这部分代码的追溯之前，我也没想到会追溯到runFinalization方法。但是工作中经常需要在各个代码块中加逻辑，有时候加了一些逻辑之后，顺便解决一下之前工作中的困惑，也是挺好的。最后提一点，网上有人喜欢在runFinalization之前先调用一下gc方法，其实没有必要，在runFinalization方法的内部，会帮你gc了。...
代码生成rapid-generator源码分析
熊猫猫
10-26 5929
原理 rapid-generator rapidDemo 假设有mysql数据库和表 修改generatorxml文件发在代码根目录就行生成代码会在classes目录加载配置文件主要是 模板文件 生成代码 rapid生成的代码文件 源码分析 常用类 加载配置文件 获取数据库元数据 构建输出模型和处理输出 总结 一个bug 感谢那位哥们提供了这样的好工具之前有个项目比较紧急，基本上开发和设计同步进行，
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值