死锁产生的原理



概述: 就是多个线程在抢占CPU的执行权的时候,出现了相互等待的状态



当代码中出现了同步嵌套的时候,并且使用两个相同的锁,就容易发生死锁;

尽量不要嵌套使用

private static String s1 = "筷子左";
private static String s2 = "筷子右";
public static void main(String[] args) {
    new Thread() {
        public void run() {
            while(true) {
                synchronized(s1) {
                    System.out.println(getName() + "...拿到" + s1 + "等待" + s2);
                    synchronized(s2) {
                        System.out.println(getName() + "...拿到" + s2 + "开吃");
                    }
                }
            }
        }
    }.start();

    new Thread() {
        public void run() {
            while(true) {
                synchronized(s2) {
                    System.out.println(getName() + "...拿到" + s2 + "等待" + s1);
                    synchronized(s1) {
                        System.out.println(getName() + "...拿到" + s1 + "开吃");
                    }
                }
            }
        }
    }.start();
}
时间: 2024-10-14 14:08:19

死锁产生的原理的相关文章

MySQL 死锁与日志二三事

最近线上 MySQL 接连发生了几起数据异常,都是在凌晨爆发,由于业务场景属于典型的数据仓库型应用,白天压力较小无法复现.甚至有些异常还比较诡异,最后 root cause 分析颇费周折.那实际业务当中咱们如何能快速的定位线上 MySQL 问题,修复异常呢?下文我会根据两个实际 case,分享下相关的经验与方法. 1.Case1:部分数据更新失败 某天渠道同学反馈某报表极个别渠道数据为 0,大部分渠道数据正常.这个数据是由一个统计程序每天凌晨例行更新的,按理来说,要么全部正常,要么全部失败,那会

GCD 死锁 多线程 --Ios

Ios中GCD死锁困扰很多人,分享一点个人经验,希望可以帮助到更多人.文章有点长,首先第一张图是正确的代码,交代一下基本流程和原理,第二张图是一个最简单的死锁后面是原理分析,第三张图稍加了一点点难度的死锁,后面是原理分析,第四章是正确的代码,后面是原理分析 一.首先来看这段 正确的  代码: 在touchesbegan中调用test方法,可以看到如下打印 分析一下原理: 1>调用test方法执,行到25行时没有开启线程,在主线程中打印 2> 执行到31行时检测到异步函数async,此时asyn

对死锁的探究

什么是死锁 死锁是进程死锁的简称,是由Dijkstra于1965年研究银行家算法时首先提出来的.它是计算机操作系统乃至并发程序设计中最难处理的问题之一. 产生死锁的必要条件 〈1〉互斥条件即某个资源在一段时间内只能由一个进程占有,不能同时被两个或两个以上的进程占有.这种独占资源如CD-ROM驱动器,打印机等等,必须在占有该资源的进程主动释放它之后,其它进程才能占有该资源.这是由资源本身的属性所决定的.如独木桥就是一种独占资源,两方的人不能同时过桥. 〈2〉不剥夺条件进程所获得的资源在未使用完毕之

11.python并发入门(part4 死锁与递归锁)

一.关于死锁. 死锁,就是当多个进程或者线程在执行的过程中,因争夺共享资源而造成的一种互相等待的现象,一旦产生了死锁,不加人工处理,程序会一直等待下去,这也被称为死锁进程. 下面是一个产生"死锁"现象的例子: import threading import time lock_a = threading.Lock() lock_b = threading.Lock() class test_thread(threading.Thread): def __init__(self): su

两个事物 update同一张表出现的死锁问题 (转载)

引言 近来做省一级计算机一级考试系统的时候,学生端进行大批量判分的时候,出现了这样的问题(事务(进程 ID 262)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品.请重新运行该事务.): 这个就是我们在代码中写了大批量的update语句,用trace Profiler ,我们对死锁追踪是这样的: 分析: 我们来分析一下上面的图,上面为DeakLock graph,图中左右两边的椭圆形相当于一个处理节点(Process Node),当鼠标移动到上面的时候,可以看到内部执行的代码,如upd

SQL Server死锁的解决过程

某现场报一个SQL死锁,于是开启了1222跟踪: dbcc traceon(1222,-1) 一段时间之后拷贝ERROR文件查找相关信息,比较有用的摘录出来如下: 语句一: select study_iuid,station_aet,modality,accession_no,patient_fk,item_attrs,start_datetime from worklist w WITH(readpast), mwl_item m where w.TAG_STUDY_INSTANCE_UID=

MySQL(InnoDB)是如何处理死锁的

MySQL(InnoDB)是如何处理死锁的 一.什么是死锁 官方定义如下:两个事务都持有对方需要的锁,并且在等待对方释放,并且双方都不会释放自己的锁. 这个就好比你有一个人质,对方有一个人质,你们俩去谈判说换人.你让对面放人,对面让你放人. 二.为什么会形成死锁 看到这里,也许你会有这样的疑问,事务和谈判不一样,为什么事务不能使用完锁之后立马释放呢?居然还要操作完了之后一直持有锁?这就涉及到 MySQL 的并发控制了. MySQL的并发控制有两种方式,一个是 MVCC,一个是两阶段锁协议.那么为

MySql一个生产死锁案例分析

接到上级一个生产环境MySQL死锁日志信息文件,需要找出原因并解决问题.我将死锁日志部分贴出如下: 在mysql中使用命令:SHOW ENGINE INNODB STATUS;总能获取到最近一些问题信息,通过搜索deadlock 关键字即可找到死锁的相关日志信息. 2019-09-25 13:28:25 7fc0301ca700InnoDB: transactions deadlock detected, dumping detailed information. 2019-09-25 13:2

详解MySQL(InnoDB)是如何处理死锁的

一.什么是死锁 官方定义如下:两个事务都持有对方需要的锁,并且在等待对方释放,并且双方都不会释放自己的锁. 这个就好比你有一个人质,对方有一个人质,你们俩去谈判说换人.你让对面放人,对面让你放人. 二.为什么会形成死锁 看到这里,也许你会有这样的疑问,事务和谈判不一样,为什么事务不能使用完锁之后立马释放呢?居然还要操作完了之后一直持有锁?这就涉及到 MySQL 的并发控制了. MySQL的并发控制有两种方式,一个是 MVCC,一个是两阶段锁协议.那么为什么要并发控制呢?是因为多个用户同时操作 M