DeadLock死锁的出现和检测-模拟死锁

最新推荐文章于 2022-05-04 15:56:34 发布
最新推荐文章于 2022-05-04 15:56:34 发布
阅读量10w+ 收藏 2
点赞数
分类专栏： 高性能编程 Lock 锁 文章标签： java 问题排查 jvm
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/hu10131013/article/details/107794412
版权
高性能编程 同时被 3 个专栏收录
60 篇文章 3 订阅
订阅专栏
锁
6 篇文章 0 订阅
订阅专栏
Lock
4 篇文章 0 订阅
订阅专栏

什么是死锁

  • 死锁： 指两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁
  • 死锁线程：上述永远互相等待的线程称为死锁线程

死锁模拟

package com.milla.study.netbase.expert.jvm;

/**
 * @Description: <模拟死锁>
 * @Author: MILLA
 * @CreateDate: 2020/4/23 15:16
 * @UpdateUser: MILLA
 * @UpdateDate: 2020/4/23 15:16
 * @UpdateRemark: <>
 * @Version: 1.0
 */
public class DeadLockDemo {
    public static String obj1 = "obj1";
    public static String obj2 = "obj2";

    public static void main(String[] args) {
        // 线程a 先获取obj1锁，然后等待3秒之后获取obj2锁，此时obj2锁已经被线程b占有，线程a就一直等待线程b释放obj2锁
        // 线程b 先获取obj2锁，然后等待3秒之后获取obj1锁，此时obj1锁已经被线程a占有，线程b就一直等待线程a释放obj2锁
        // 最终线程a和线程b陷入一个先有蛋还是先有鸡的循环等待问题，此时产生死锁
        Thread a = new Thread(new Lock1());
        Thread b = new Thread(new Lock2());
        a.start();
        b.start();
    }
}

class Lock1 implements Runnable {
    @Override
    public void run() {
        try {
            System.out.println("Lock1 running");
            while (true) {
                synchronized (DeadLockDemo.obj1) {
                    System.out.println("Lock1 lock obj1");
                    //获取obj1后先等一会儿，让Lock2有足够的时间锁住obj2
                    Thread.sleep(3000);
                    synchronized (DeadLockDemo.obj2) {
                        System.out.println("Lock1 lock obj2");
                    }
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

class Lock2 implements Runnable {
    @Override
    public void run() {
        try {
            System.out.println("Lock2 running");
            while (true) {
                synchronized (DeadLockDemo.obj2) {
                    System.out.println("Lock2 lock obj2");
                    Thread.sleep(3000);
                    synchronized (DeadLockDemo.obj1) {
                        System.out.println("Lock2 lock obj1");
                    }
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

因为资源竞争导致死锁

 查看进程情况

# 查看进程号
[root@localhost ~]# jcmd -l
15808 com.milla.study.netbase.expert.jvm.DeadLockDemo
21312 sun.tools.jcmd.JCmd -l

# 查看进程的堆栈信息
[root@localhost ~]# jstack 15808
2020-08-04 18:24:02
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):

"DestroyJavaVM" #15 prio=5 os_prio=0 tid=0x0000000003477000 nid=0x265c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #14 prio=5 os_prio=0 tid=0x0000000023705000 nid=0x2f58 waiting for monitor entry [0x000000002428e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
       # 可以定位在发生死锁的大致位置
        at com.milla.study.netbase.expert.jvm.Lock2.run(DeadLockDemo.java:59)
        - waiting to lock <0x000000074121ec30> (a java.lang.String)
        - locked <0x000000074121ec60> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #13 prio=5 os_prio=0 tid=0x0000000023702000 nid=0x459c waiting for monitor entry [0x000000002418f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.milla.study.netbase.expert.jvm.Lock1.run(DeadLockDemo.java:39)
        - waiting to lock <0x000000074121ec60> (a java.lang.String)
        - locked <0x000000074121ec30> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

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

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

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

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

"JDWP Command Reader" #8 daemon prio=10 os_prio=0 tid=0x0000000021771000 nid=0xc78 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Event Helper Thread" #7 daemon prio=10 os_prio=0 tid=0x000000002176d800 nid=0x1164 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Transport Listener: dt_socket" #6 daemon prio=10 os_prio=0 tid=0x0000000021760000 nid=0x4ec4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000002171f000 nid=0x2cb0 in Object.wait() [0x0000000022a8e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000740c08ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000740c08ec8> (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=0x0000000003567000 nid=0x4284 in Object.wait() [0x000000002298e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000740c06b68> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x0000000740c06b68> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x00000000216f7800 nid=0x1dd0 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000348c800 nid=0x50e8 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000348e800 nid=0x4054 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000003490000 nid=0x2384 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000003491800 nid=0x1f00 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x00000000236a5000 nid=0x19d8 waiting on condition

JNI global references: 1702


Found one Java-level deadlock: # 找到了一个死锁
=============================
"Thread-1": # 
  waiting to lock monitor 0x00000000216fe0a8 (object 0x000000074121ec30, a java.lang.String),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00000000216fb768 (object 0x000000074121ec60, a java.lang.String),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1": # 线程1已经获取0x000000074121ec60锁，在等待获取0x000000074121ec30锁
        at com.milla.study.netbase.expert.jvm.Lock2.run(DeadLockDemo.java:59)
        - waiting to lock <0x000000074121ec30> (a java.lang.String)
        - locked <0x000000074121ec60> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0": # 于此同时 线程0已经获取了0x000000074121ec30锁，在等待0x000000074121ec60锁
        at com.milla.study.netbase.expert.jvm.Lock1.run(DeadLockDemo.java:39)
        - waiting to lock <0x000000074121ec60> (a java.lang.String)
        - locked <0x000000074121ec30> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.
# 以上两个线程，在都不放弃之前锁的情况下，就这么一直等待，就产生了死锁

 此时就发现了死锁，基本能定位发生死锁代码的位置，方便程序员进行代码定位

因为代码原因导致的死锁 

package com.milla.study.netbase.expert.jvm;

/**
 * @Description: <消费代码写的有问题带来的死锁>
 * @Author: MILLA
 * @CreateDate: 2020/4/23 15:16
 * @UpdateUser: MILLA
 * @UpdateDate: 2020/4/23 15:16
 * @UpdateRemark: <>
 * @Version: 1.0
 */
public class ConsumerProductDeadLock {
    /**
     * 生产货物
     */
    public static Object product = null;

    /**
     * 会导致程序永久等待的wait/notify
     */
    public void waitNotifyDeadLockTest() throws Exception {
        // 启动消费者线程
        new Thread(() -> {
            //没有货物可消费需要进行等待
            if (product == null) {
                try {
                    Thread.sleep(5000L);
                } catch (InterruptedException e1) {
                    e1.printStackTrace();
                }
                synchronized (this) {
                    try {
                        System.out.println("1、进入等待，线程ID为： " + Thread.currentThread().getId());
                        this.wait(); // 多次查看
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
            System.out.println("2、买到获取，回家");
        }).start();
        // 此时休眠的时间比没有货物休眠的时间端，导致下面的代码先运行，已经执行了this.notifyAll();
        // 致使wait的线程永远也不会被唤醒导致死锁
        Thread.sleep(3000L);
        product = new Object();
        synchronized (this) {
            this.notifyAll();
            System.out.println("3、通知消费者");
        }
    }

    public static void main(String[] args) throws Exception {
        new ConsumerProductDeadLock().waitNotifyDeadLockTest();
    }
}

当使用 wait()和notifyAll()不当的时候，极有可能产生死锁，仍然需要通过堆栈信息进行排查才能定位和解决死锁问题

 

涟漪海洋
关注
专栏目录
操作系统实验11：死锁检测算法模拟实现
Planck Chang' blog
10-26 536
操作系统实验11：死锁检测算法模拟实现
AXI Deadlock死锁解析
最新发布
weixin_44157334的博客
04-03 1975
如下图所示，m1发出读cmd的顺序是m1_0_s1, m1_0_s2, 因为id（id都为0）相同，所以master port1端口为了符合AXI协议，该端口必须先接受来自s1的数据，后接收来自s2的数据。m2发出读cmd的顺序是m2_0_s2, m2_0_s1, 因为id（id都为0）相同，所以master port2端口为了符合AXI协议，该端口必须先接受来自s2的数据，后接收来自s1的数据。该示例为二阶死锁，当master和slave个数大于2时，也可以形成高阶死锁。由此，形成循环依赖，陷入死锁。
go-deadlock:go (golang) 中的在线死锁检测
08-04
go (golang) 中的在线死锁检测。 为什么 死锁发生并且调试起来很痛苦。 什么 go-deadlock 为 sync.(RW)Mutex 提供了 (RW)Mutex 的替代品。 如果您创建频道的意大利面，它将不起作用。 仅互斥体。 安装 go get github.com/sasha-s/go-deadlock/... 用法 import "github.com/sasha-s/go-deadlock" var mu deadlock. Mutex // Use normally, it works exactly like sync.Mutex does. mu . Lock () defer mu . Unlock () // Or var rw deadlock. RWMutex rw . RLock () defer rw . RUnlock () 死锁 最常见的死锁来源
死锁问题
m0_53917137的博客
03-04 160
死锁问题 所谓死锁是指两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。 死锁产生的原因 1、系统资源的竞争。通常系统中拥有的不可剥夺资源，其数量不足以满足多个进程运行的需要，使得进程在运行过程中，会因争夺资源而陷入僵局，如磁带机、打印机等。 2、不剥夺性条件。只有对不可剥夺资源的竞争才可能产生死锁，对可剥夺资源的竞争是不会引起死锁的。 3、进程推进顺序非法。进程在运行过程中，请求和释放资源的顺序不当，也同样会导致死锁。例如，并发进程P1、P2分别
模拟死锁检测算法[死锁检测算法实现]
09-06
死锁检测算法：当任一进程Pj申请一个已被其他进程占用的资源ri时，进行死锁检测。检测算法通过反复查找进程等待表和资源分配表， 来确定进程Pj对资源ri的请求是否导致形成环路，若是，便确定出现死锁。
实测有效的一个c++检测线程死锁的解决方法（实现和测试代码）
05-22
原创实测有效的一个c++检测线程死锁的解决方法，已应用于项目，实测有效 原创文章地址：https://blog.csdn.net/liaozhilong88/article/details/80354414
用C语言实现死锁检测.rar_c语言判断死锁_deadlock_死锁_死锁 检测_死锁c语言
09-20
在C语言中实现死锁检测是一项技术性的挑战，因为这涉及到操作系统原理和多线程编程。本文将深入探讨如何使用C语言来检测死锁，并分析涉及的相关概念和技术。 首先，我们要理解死锁的基本条件：互斥、占有并等待、无...
死锁2---马克-to-win java视频
06-07
死锁2deadlock---马克-to-win java视频的详细的描述与介绍
死锁1---马克-to-win java视频
06-07
死锁1deadlock---马克-to-win java视频的详细描述与介绍
SQL Server上的一个奇怪的Deadlock及其分析方法
03-24
SQL Server上的一个奇怪的Deadlock及其分析方法
C语言实现死锁的检测与解除（含源代码）
weixin_46447549的博客
04-19 7812
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录一、编程内容二、死锁检测1.数据结构2.算法三、死锁解除四、源码五、运行结果1.不会发生死锁的情况：2.会发生死锁的情况： 一、编程内容 处理进程死锁的方法一般包括：预防死锁，避免死锁，死锁的检测与解除。其中，预防死锁和避免死锁是采用事先预防的策略。预防死锁通过破坏产生死锁的四个必要条件中的一个或几个来实现，而预防死锁主要利用银行家算法来进行事先预防。 如果在系统中，既不采取死锁预防措施，也未配有死锁避免算法，系统很可能就会发生死
死锁检测与解除
严同学在努力
01-05 2133
详讲死锁的检测和解除，听得懂的人也应该听懂了，没听懂的来我这里。保你听懂
MySQL DeadLock故障排查过程
die7030的博客
01-02 407
【作者】 刘博：携程技术保障中心数据库高级经理，主要关注Sql server和Mysql的运维和故障处理。 【环境】 版本号：5.6.21 隔离级别：REPEATABLE READ 【问题描述】 接到监控报警，有一个线上的应用DeadLock报错，每15分钟会准时出现，报错统计如下图： 登录Mysql服务器查看日志： mysql> show engine innodb statu...
Mysql DeadLock 死锁
u013269532的专栏
03-06 232
表结构 CREATE TABLE `t_custom_sku_price` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `customSkuId` BIGINT(20) DEFAULT NULL COMMENT '自定义skuid', `priceType` INT(11) DEFAULT NULL COMMENT...
jstack命令定位死锁
手写ArrayList
11-24 468
同样的，写一个死锁代码片段，发布到虚拟机，访问引起死锁的接口。 排查步骤： 使用top或者jps定位到项目进程pid； [root@localhost webapps]# jps 6944 springboot.jar 7124 Jps 获取进程pid后直接使用命令：jstack -l 6944，打印线程dump，然后全文搜索deadlock Found one Java-level d...
同步、通信与死锁
DJ5789121的博客
01-15 1470
进程的同步与互斥 在多道程序的环境中，系统中的多个进程可以并发执行，同时它们又要共享系统中的资源，由此诸进程间会产生错综复杂的相互制约的关系。 一、进程间制约关系 1.竞争关系    源于资源共享，多个不存在逻辑关系的进程因共享资源而产生制约关系。     若一个进程要求使用某一资源，而该资源正被另一个进程使用，并且这一资源不允许两个进程同时访问，那么该进程只有等待，
死锁跟踪：6种跟踪死锁的方法总结
weixin_30855099的博客
11-12 174
原文地址：http://blog.csdn.net/kk185800961/article/details/42504857 方法一：Windows 性能计数器监控 命令行输入：perfmon 或者 perfmon /sys 选择实例：SQL Server :Locks \\ Number of DeadLocks/sec \\ _Total （只能知道什么时候发生死锁，看不得具体...
Java锁——死锁及排查
枫陵的博客
05-04 351
概念 死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象，若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。 死锁产生主要原因 1. 进程运行推进的顺序不合适 2. 资源分配不当 3. 系统资源不足 代码示例 线程a,b相互持有并期望，造成死锁 public class DeadLockDemo { static Object lockA = n...
C语言实现死锁检测方法详解
资源摘要信息: "用C语言实现死锁检测" 是一份专注于在操作系统领域中，特别是在C语言编程环境下对死锁问题进行检测和处理的教程或代码示例。死锁是并发编程中的一个常见问题，通常发生在多个进程或线程互相等待对方...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值