死锁相关

从服务能力层面上，我们不允许出现死锁，这是对于系统资源的浪费。

工程结构中不允许出现死锁，我们应该尽可能的进行规避。

结论优先

多个线程在并发执行过程中，互相争夺对方已持有的锁，造成“无限期”等待

原因

互斥条件：一个资源每次只能被一个进程使用。

请求和保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

不可抢占条件:进程已获得的资源，在末使用完之前，不能强行剥夺，只能在进程使用完时由自己释放。

循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

基本条件

死锁的本质

单模型数据批量操作的互相等待

跨模型数据操作的互相等待

场景

多线程中批量操作单模型数据，顺序乱序，导致互相等待。

多线程中在各自事务场景对于同一批不同模型进行操作，并且顺序并不一致。

事务中（Mysql为例）

使用Redis实现分布式锁，多线程之间加锁出现乱序交叉，导致互相等待。

非事务(redis为例)

虽然上述实例都在描述多线程，实际单线程也有死锁死锁风险。简单的：1、当所使用redis分布式锁不支持重入，而使用场景中重复获取同一把锁。

更多的

场景细分

多线程交叉竞争

单线程自身重复竞争

单模型数据

多模型数据

问题场景分类

因不同线程互相等待，最终会导致链接超时。

Redis

当两个线程发生死锁时，Mysql会出现死锁异常。

1213 - Deadlock found when trying to get lock; try restarting transaction

特殊的：开始事务后执行一个批量SQL，InnoDB在加行锁时都是做了默认排序后逐个添加，等于Mysql默认帮我们做了排序。此时无死锁风险。

Mysql

问题现象

固定的顺序是避免死锁的有效保障，不论是手动排序还是依赖Mysql自动排序，都是不可缺少的一个环节。

注：此处的无死锁风险是指单表操作简单场景下，如果是多表操作仅靠简单的单表排序是规避比了死锁风险的。则需要考虑不同领域模型在同一线程中的操作顺序固定下来。

破坏循环等待条件（有序资源使用法）

切入点A

但是，基于数据层的底层逻辑中，当批量操作数据时，是否有条件“一次性”申请到所需所有资源。比如：当操作Mysql批量数据的时候底层逻辑仍然是循环获取行级锁。

破坏“请求/保持条件”：每个进程执行之前，必须一次性地申请其在整个运行期间所需的全部资源，全部申请到了才能运行。这样它在整个运行过程中便不会再提出资源请求，从而破坏了“请求”条件。

受制于功能需求和所设计的事务范围。比如：当在Mysql同一个事务需要循环更新一批数据，并且更新结果需要保持一致，不接受部分成功即需要在同一个事务中完成上述内容，此时，则不存在“破坏保持条件”的可行性。

 并且，在功能结构设计上，应该尽可能的避免非必要的“保持”现象。如果说要依赖该节点来解决“死锁”，那说明这个“死锁”本身也是额外造成的、非必需的。

破坏“保持”条件每个进程提出申请资源前必须释放已占有的一切资源

切入点B

解决思路

等待而非阻断：当多个线程并发对于同一条数据或者同一批数据进行操作时，我们常见的需求场景是接受等待，而非直接阻断业务流程。注：这里跟sql执行结果（即业务执行结果）无关，而是是否执行的策略。

业务可能接受死锁：按上述所说，数据持久层本身不应该也不适合通过异常来控制业务逻辑，但不一定满足不了业务需求，如下述例B。

但是，更多的问题是在我们明明不接受死锁，并且没有任何处理措施的情况下出现了死锁。

业务场景需求

子主题

例A：库存扣减，多个线程同时对于某一个sku进行库存更新。【特点】在同一个事务中批量更新多条记录，不同线程的批量更新无业务逻辑上的冲突或依赖，业务结果不唯一。【业务分析】该场景下各个线程依次完成库存更新，不允许出现死锁，即批量数据中有重叠数据时，应该竞争行锁，达到都执行库存更新的结果。此时如果SQL异常，则不满足业务需求。同时，库存的更新有库存扣减、库存返还，其中，库存扣减不一定能执行成功（库存不足），但是在数据持久层中，我们不关心业务逻辑。即数据库只需要按照上述整体策略完成SQL执行，反馈effact rows给上层业务层即可，后续逻辑控制工作由业务层处理。

例B：有一批数据原始状态是A，可以同时在两个场景中进行更新，不同场景更新的目标状态不一样分别是B、C，两者皆为终态互相不能流转。【特点】在同一个事务中批量更新多条记录，不同线程的批量更新有业务逻辑上的冲突或依赖，业务结果不唯一。【业务分析】该场景下各个线程依次完成库存更新，此时如果因死锁导致SQL异常，但可以保证一个线程执行成功，而根据业务场景中，无论哪种业务结果皆为终态，则可以认为这种处理不影响业务。但，同上述“基本策略”所述，这种方式虽然满足业务需求，会带来工程结构上的侵入、额外的异常日志，并不推荐。

【细节】上述例A和例B有个重要区别，即例A同一批数据操作中的更新目标值可能并不一样，而例B则本身同一个操作中的同批次数据目标更新值必然相同，带来的实现区别是：例A中更新目标值不一致，则具体的SQL语法无法使用IN，即无法依赖Mysql的自动排序，需要手动额外处理。

实例

重复持有锁的评估

有序使用资源

在保证各个单模型数据的上述解决策略基础上，保障各个模型组合操作在不同场景下的操作顺序固定。

解决方案

取决于业务需要，有的业务不允许出现死锁，有的可以。

从技术实现层面上讲，应尽可能避免死锁，通过更友好合理的方式来控制业务逻辑。

不应该使用Mysql或者其他等数据持久层中的异常来控制逻辑和业务结果。原因：（1）点对点异常识别成本较大，且会额外造成无用干扰日志。（2）在工程结构中，数据持久层不需要对业务逻辑控制负责。

工程中不允许出现死锁，我们应该尽可能的进行规避。

结论

应用层

死锁