活锁

活锁

 
活锁(英文 livelock),指事物1可以使用资源,但它让其他事物先使用资源;事物2可以使用资源,但它也让其他事物先使用资源,于是两者一直谦让,都无法使用资源。
所谓饥饿,是指如果 事务T1封锁了数据R,事务T2又请求封锁R,于是T2等待。T3也请求封锁R,当T1释放了R上的封锁后,系统首先批准了T3的请求,T2仍然等待。然后T4又请求封锁R,当T3释放了R上的封锁之后,系统又批准了T4的请求......T2可能永远等待,这就是饥饿。
活锁有一定几率解开。而死锁(deadlock)是无法解开的。
避免活锁的简单方法是采用先来先服务的策略。当多个 事务请求封锁同一 数据对象时,封锁子系统按请求封锁的先后次序对事务排队,数据对象上的锁一旦释放就批准申请队列中第一个事务获得锁。
### 事务的概念 在数据库管理系统中,(Livelock),也称为饥饿现象,指的是某个事务由于总是被其他优先级更高的事务抢占资源而永远无法获得所需的资源来继续执行的情况。尽管不存在真正的阻塞或等待循环,但是该事务始终未能成功获取所需资源并完成其工作。 ### 产生的原因 通常发生在高并发环境下,当多个事务竞争相同资源时可能发生。具体来说: - 当一个低优先级的事务试图访问某项资源时,如果此时有更高优先级的新到来事务也需要同一资源,则系统可能会选择先满足后者的需求; - 如果这种情况持续发生,即每次较低级别的请求刚要得到服务就被更紧急的任务打断,那么这个原本应该被执行的操作就可能无限期地推迟下去[^1]。 ### 解决方案 为了防止的发生,可以采取以下几种策略: #### 设置超时机制 给每一个等待中的事务设定最大允许等待时间。一旦超过此期限仍未获得所需资源,则自动放弃当前尝试,并按照预定义的方式处理失败情况,比如回滚或者重新排队。 #### 实施公平调度算法 确保所有正在等待特定资源的事务都能按顺序依次获得它们所需要的资源。这可以通过引入队列结构来管理待处理的请求列表,在分配资源时遵循先进先出原则(FIFO),从而保障每个事务都有机会最终取得进展。 #### 使用随机延迟重试逻辑 对于那些因为暂时性冲突而未成功的操作,不是立即再次发起相同的请求而是加入一段短暂且带有一定随机性的延时期间后再做尝试。这种方法有助于打破可能导致连续失败的竞争模式,减少因频繁争抢造成的不公平状况。 ```sql -- SQL伪代码示例外观上展示如何设置超时参数 (不同DBMS语法有所差异) SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN WORK; -- 开始一个新的事务 SAVEPOINT sp1; UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A'; IF NOT EXISTS(SELECT * FROM accounts WHERE account_id = 'B' AND balance >= 100) THEN ROLLBACK TO SAVEPOINT sp1; END IF; -- 假设这里设置了超时控制语句 -- 这只是一个示意,实际应用需参照具体的DBMS文档 EXECUTE IMMEDIATE 'ALTER SYSTEM SET lock_timeout=5000'; UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B'; COMMIT; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值