死锁的四个必要条件：
互斥条件(Mutual exclusion)：资源不能被共享，只能由一个进程使用。
请求与保持条件(Hold and wait)：已经得到资源的进程可以再次申请新的资源。
非剥夺条件(No pre-emption)：已经分配的资源不能从相应的进程中被强制地剥夺。
循环等待条件(Circular wait)：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。
系统背景:
日处理数据不到10W,总数据千万+的中小型业务系统,运行2年半,基本上每2周迭代一次
最近业务操作时不时报出死锁被牺牲,每天出现2,3次,概率很低 但是一直存在
出现问题以后,我们首先做的就是把业务操作异步处理,业务提交的数据,做基本的检查之后就放到队列中,然后队列再去循环处理队列的数据
这样并发的概率减小了,就算再次死锁,客户也不会感知到
然后降低单次事务的处理时长;
1.把查询SQL拿出事务单独查询,
2.对于一些对时效不敏感的可以异步处理的业务剥离开来,晚上再集中批次处理
3.对于事务处理中有依赖于外部接口数据的,可以先调用接口再开启事务,对接口的访问一定不要直接放入事务中
然后我们分析为什么会出现死锁
根据死锁的原则,必然是出现了SQL执行顺序不当,导致循环等待,以下是分析死锁出现的程序
线程A和B同时执行,看执行结果,
线程A修改表1->等待2秒->线程B修改表2->等待2秒->线程B修改表1等待A->线程A修改表2等待B 死锁
线程A:修改锁住表1->等待2秒->修改表2 此时表2被锁住了 等待B释放
线程B:修改锁住表2->等待2秒->修改表1 此时表1是被锁住的 等待A释放
修改脚本的执行顺序就能解决此死锁.
业务系统处理此问题 给每个表制定编号,然后检查系统按照此编号来执行修改
