并发(6)死锁

一个对象可以有synchronized方法或者其他形式的加锁机制来防止别的任务在互斥还没有释放的时候就访问该对象,所以就会出现一种情况,A阻塞等待B,B阻塞等待C...Z阻塞等待A。这种任务之间互相等待的连续循环,没有哪个线程能继续,称之为死锁

哲学家就餐问题就是一个经典的死锁例证。五位哲学家,五双筷子,有时候思考,有时候就餐,就餐时需要两双筷子,当一个哲学家拿起两双筷子就餐时,另外一个人也需要就餐就需要等待筷子被放下。

死锁发生的四个条件:

(1)互斥条件。任务使用的资源至少有一个是不能共享的。

(2)至少有一个任务必须持有一个资源,并且等待获取一个当前被别的任务持有的资源。

(3)资源不能被任务抢占。

(4)必须有循环等待,一个任务等待其他任务所持有的的资源,后面的任务依赖这个任务的资源,最后的任务又依赖第一个任务持有的资源,使大家都被锁住。

防止死锁,只需破坏其中一个条件即可。比如等待一段时间后就放弃等待。

### 解决高并发场景下的 MySQL 死锁问题 #### 设置事务超时时间 为了防止长时间等待造成的资源浪费,可以在应用程序配置文件中设定较短的事务超时时间。一旦超过指定的时间间隔仍未完成,则强制终止当前正在执行中的事务[^3]。 ```yaml spring: datasource: hikari: connection-timeout: 20000 # 连接超时时间为20秒 max-lifetime: 1800000 # 最大生命周期为30分钟 idle-timeout: 60000 # 空闲连接回收周期为60秒 ``` #### 合理规划锁策略 对于频繁更新的数据行,在设计阶段就应考虑采用合适的锁定粒度;尽量缩短持有排他锁的时间长度,避免不必要的长事务运行。另外,确保所有程序按照相同的顺序获取多个对象上的锁也可以有效预防循环依赖引发的死锁现象。 #### 减少共享资源竞争 通过调整业务流程或数据结构来降低不同进程间争夺同一份资料的可能性。例如,在处理涉及跨表关联的操作时,可尝试拆分复杂查询成若干简单子任务分别提交给数据库服务器独立完成后再汇总结果集返回前端展示层[^4]。 #### 使用乐观并发控制(Optimistic Concurrency Control) 相比于传统的悲观方式总是假设冲突不可避免因而提前施加严格限制而言,OCC允许读取者自由访问副本直到最后确认修改前才会检查是否有其他方抢先一步进行了变更。如果确实发生了碰撞则提示重试而非立即报错中断整个交易链路[^2]。 #### 定期监控与调优 部署专业的运维工具持续跟踪线上环境内各项指标表现情况,及时发现潜在隐患并采取针对性措施加以改进优化。比如针对特定时间段内的热点SQL语句做专项治理工作,提高其效率从而间接缓解因排队等候而产生的压力[^1]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值