并发控制之活锁和死锁

封锁技术可以有效地解决并行操作的一致性问题,但也带来一些新的问题
死锁
活锁

活锁

事务T1封锁了数据R
事务T2又请求封锁R,于是T2等待。
T3也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待。
T4又请求封锁R,当T3释放了R上的封锁之后系统又批准了T4的请求……
T2有可能永远等待,这就是活锁的情形
在这里插入图片描述

避免活锁:采用先来先服务的策略

当多个事务请求封锁同一数据对象时
按请求封锁的先后次序对这些事务排队
该数据对象上的锁一旦释放,首先批准申请队列中第一个事务获得锁

死锁

事务T1封锁了数据R1
T2封锁了数据R2
T1又请求封锁R2,因T2已封锁了R2,于是T1等待T2释放R2上的锁
接着T2又申请封锁R1,因T1已封锁了R1,T2也只能等待T1释放R1上的锁
这样T1在等待T2,而T2又在等待T1,T1和T2两个事务永远不能结束,形成死锁
在这里插入图片描述

解决死锁的方法

两类方法
1.死锁的预防
2. 死锁的诊断与解除

死锁的预防

产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求对已为其他事务封锁的数据对象加锁,从而出现死等待。
预防死锁的发生就是要破坏产生死锁的条件

预防死锁的方法

(1) 一次封锁法
要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行
存在的问题
降低系统并发度
难于事先精确确定封锁对象
数据库中数据是不断变化的,原来不要求封锁的数据,在执行过程中可能会变成封锁对象,所以很难事先精确地确定每个事务所要封锁的数据对象。
解决方法:将事务在执行过程中可能要封锁的数据对象全部加锁,这就进一步降低了并发度。
(2)顺序封锁法
顺序封锁法是预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实行封锁。
顺序封锁法存在的问题
维护成本
数据库系统中封锁的数据对象极多,并且随数据的插入、删除等操作而不断地变化,要维护这样的资源的封锁顺序非常困难,成本很高。
难以实现
事务的封锁请求可以随着事务的执行而动态地决定,很难事先确定每一个事务要封锁哪些对象,因此也就很难按规定的顺序去施加封锁

结论

在操作系统中广为采用的预防死锁的策略并不太适合数据库的特点
数据库管理系统在解决死锁的问题上更普遍采用的是诊断并解除死锁的方法

死锁的诊断与解除

死锁的诊断
(1) 超时法
如果一个事务的等待时间超过了规定的时限,就认为发生了死锁
优点:实现简单
缺点
有可能误判死锁
时限若设置得太长,死锁发生后不能及时发现
(2)等待图法
用事务等待图动态反映所有事务的等待情况
事务等待图是一个有向图G=(T,U)
T为结点的集合,每个结点表示正运行的事务
U为边的集合,每条边表示事务等待的情况
若T1等待T2,则T1,T2之间划一条有向边,从T1指向T2
在这里插入图片描述

图(a)中,事务T1等待T2,T2等待T1,产生了死锁
图(b)中,事务T1等待T2,T2等待T3,T3等待T4,T4又等待T1,产生了死锁
图(b)中,事务T3可能还等待T2,在大回路中又有小的回路
并发控制子系统周期性地(比如每隔数秒)生成事务等待图,检测事务。如果发现图中存在回路,则表示系统中出现了死锁。
解除死锁
选择一个处理死锁代价最小的事务,将其撤消
释放此事务持有的所有的锁,使其它事务能继续运行下去
欢迎大家加我微信交流讨论(请备注csdn上添加)
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程子的小段

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值