diff --git a/notes/pics/deadlock-banker-multi.png b/notes/pics/deadlock-banker-multi.png new file mode 100644 index 00000000..95c57b6d Binary files /dev/null and b/notes/pics/deadlock-banker-multi.png differ diff --git a/notes/pics/deadlock-banker-single.png b/notes/pics/deadlock-banker-single.png new file mode 100644 index 00000000..f11d25fb Binary files /dev/null and b/notes/pics/deadlock-banker-single.png differ diff --git a/notes/pics/deadlock-detect-graph.png b/notes/pics/deadlock-detect-graph.png new file mode 100644 index 00000000..4fc166d7 Binary files /dev/null and b/notes/pics/deadlock-detect-graph.png differ diff --git a/notes/pics/deadlock-detect-matrix.png b/notes/pics/deadlock-detect-matrix.png new file mode 100644 index 00000000..643e2907 Binary files /dev/null and b/notes/pics/deadlock-detect-matrix.png differ diff --git a/notes/pics/deadlock-safe-state.png b/notes/pics/deadlock-safe-state.png new file mode 100644 index 00000000..bb8da385 Binary files /dev/null and b/notes/pics/deadlock-safe-state.png differ diff --git a/notes/pics/deadlock-transfer.png b/notes/pics/deadlock-transfer.png new file mode 100644 index 00000000..f6deebb3 Binary files /dev/null and b/notes/pics/deadlock-transfer.png differ diff --git a/notes/计算机操作系统 - 死锁.md b/notes/计算机操作系统 - 死锁.md index 2b81337b..f7c8ab44 100644 --- a/notes/计算机操作系统 - 死锁.md +++ b/notes/计算机操作系统 - 死锁.md @@ -17,12 +17,16 @@ * [1. 安全状态](#1-安全状态) * [2. 单个资源的银行家算法](#2-单个资源的银行家算法) * [3. 多个资源的银行家算法](#3-多个资源的银行家算法) + * [程序中的死锁](#程序中的死锁) + * [1. Java 线程死锁](#1-java-线程死锁) + * [2. MySQL 死锁](#2-mysql-死锁) + * [参考资料](#参考资料) ## 必要条件 -

+

- 互斥：每个资源要么已经分配给了一个进程，要么就是可用的。 - 占有和等待：已经得到了某个资源的进程可以再请求新的资源。 @@ -54,26 +58,26 @@ ### 1. 每种类型一个资源的死锁检测 -

+

上图为资源分配图，其中方框表示资源，圆圈表示进程。资源指向进程表示该资源已经分配给该进程，进程指向资源表示进程请求获取该资源。 -图 a 可以抽取出环，如图 b，它满足了环路等待条件，因此会发生死锁。 +图中 P1、P2、P3 和 R1、R2、R3 构成一个环，满足环路等待条件，因此发生了死锁。 每种类型一个资源的死锁检测算法是通过检测有向图是否存在环来实现，从一个节点出发进行深度优先搜索，对访问过的节点进行标记，如果访问了已经标记的节点，就表示有向图存在环，也就是检测到死锁的发生。 ### 2. 每种类型多个资源的死锁检测 -

+

-上图中，有三个进程四个资源，每个数据代表的含义如下： +上图中，有三个进程三种资源，每个数据代表的含义如下： - E 向量：资源总量 - A 向量：资源剩余量 - C 矩阵：每个进程所拥有的资源数量，每一行都代表一个进程拥有资源的数量 - R 矩阵：每个进程请求的资源数量 -进程 P1 和 P2 所请求的资源都得不到满足，只有进程 P3 可以，让 P3 执行，之后释放 P3 拥有的资源，此时 A = (2 2 2 0)。P2 可以执行，执行后释放 P2 拥有的资源，A = (4 2 2 1) 。P1 也可以执行。所有进程都可以顺利执行，没有死锁。 +进程 P1 和 P3 所请求的资源都得不到满足，只有进程 P2 可以，让 P2 执行，之后释放 P2 拥有的资源，此时 A = (3 1 2)。P1 可以执行，执行后释放 P1 拥有的资源，A = (4 2 2)。P3 也可以执行。所有进程都可以顺利执行，没有死锁。 算法总结如下： @@ -115,9 +119,9 @@ ### 1. 安全状态 -

+

-图 a 的第二列 Has 表示已拥有的资源数，第三列 Max 表示总共需要的资源数，Free 表示还有可以使用的资源数。从图 a 开始出发，先让 B 拥有所需的所有资源（图 b），运行结束后释放 B，此时 Free 变为 5（图 c）；接着以同样的方式运行 C 和 A，使得所有进程都能成功运行，因此可以称图 a 所示的状态时安全的。 +图中条形的长度表示进程总共需要的资源数（Max），浅蓝部分表示已拥有的资源数（Has），Free 表示还可以使用的资源数。从图 a 开始出发，先让 B 拥有所需的所有资源，运行结束后释放 B，此时 Free 变为 6（图 b）；接着以同样的方式运行 A 和 C，使得所有进程都能成功运行，因此可以称图 a 所示的状态是安全的。 定义：如果没有死锁发生，并且即使所有进程突然请求对资源的最大需求，也仍然存在某种调度次序能够使得每一个进程运行完毕，则称该状态是安全的。 @@ -127,20 +131,96 @@ 一个小城镇的银行家，他向一群客户分别承诺了一定的贷款额度，算法要做的是判断对请求的满足是否会进入不安全状态，如果是，就拒绝请求；否则予以分配。 -

+

-上图 c 为不安全状态，因此算法会拒绝之前的请求，从而避免进入图 c 中的状态。 +上图 b 为不安全状态，因此算法会拒绝 C 的这次申请，从而避免进入图 b 中的状态；图 c 仍然是安全的，可以分配。 ### 3. 多个资源的银行家算法 -

+

-上图中有五个进程，四个资源。左边的图表示已经分配的资源，右边的图表示还需要分配的资源。最右边的 E、P 以及 A 分别表示：总资源、已分配资源以及可用资源，注意这三个为向量，而不是具体数值，例如 A=(1020)，表示 4 个资源分别还剩下 1/0/2/0。 +上图中有四个进程，三种资源。Allocation 表示已经分配的资源，Need 表示还需要分配的资源。E 和 Available 分别表示总资源和可用资源，它们都是向量，而不是具体数值，例如 Available = (1 1 2) 表示 3 种资源分别还剩下 1、1、2 个。 检查一个状态是否安全的算法如下： -- 查找右边的矩阵是否存在一行小于等于向量 A。如果不存在这样的行，那么系统将会发生死锁，状态是不安全的。 -- 假若找到这样一行，将该进程标记为终止，并将其已分配资源加到 A 中。 +- 查找 Need 矩阵中是否存在一行小于等于向量 Available。如果不存在这样的行，那么系统将会发生死锁，状态是不安全的。 +- 假若找到这样一行，将该进程标记为终止，并将其已分配资源加到 Available 中。 - 重复以上两步，直到所有进程都标记为终止，则状态是安全的。 如果一个状态不是安全的，需要拒绝进入这个状态。 + +## 程序中的死锁 + +### 1. Java 线程死锁 + +两个线程反向转账时，T1 锁住 alice 再请求 bob，T2 锁住 bob 再请求 alice，就是开头图中的情况： + +```java +static void transfer(Account from, Account to, int amount) { + synchronized (from) { + synchronized (to) { + from.balance -= amount; + to.balance += amount; + } + } +} +``` + +用 jstack 查看进程的线程栈，末尾会直接报告死锁（省略了部分内容）： + +```text +Found one Java-level deadlock: +============================= +"T1": + waiting to lock monitor 0x0000000135f26a70 (object 0x000000061fc14e18, a Transfer$Account), + which is held by "T2" + +"T2": + waiting to lock monitor 0x0000000125f06e60 (object 0x000000061fc14dd0, a Transfer$Account), + which is held by "T1" +``` + +解决方法是破坏环路等待：所有线程按同一个顺序加锁，例如总是先锁 id 小的账户。 + +```java +Account first = from.id < to.id ? from : to; +Account second = from.id < to.id ? to : from; +synchronized (first) { + synchronized (second) { + from.balance -= amount; + to.balance += amount; + } +} +``` + +两个线程各反向转账 10 万次，原来的写法每次运行都会卡住，按 id 顺序加锁后都能完成，两个账户的余额仍为 1000。使用 ReentrantLock 时还可以用 tryLock 设置超时，拿不到锁就释放已持有的锁再重试，破坏的是占有和等待条件。 + +### 2. MySQL 死锁 + +事务按不同的顺序更新同一组行时也会死锁。例如两个事务同时反向转账，事务 1 先更新 id = 1，事务 2 先更新 id = 2，之后各自更新对方已经锁住的行： + +```sql +-- 事务 1 +BEGIN; +UPDATE account SET balance = balance - 100 WHERE id = 1; +UPDATE account SET balance = balance + 100 WHERE id = 2; -- 等待事务 2 释放 id = 2 的行锁 + +-- 事务 2 +BEGIN; +UPDATE account SET balance = balance - 50 WHERE id = 2; +UPDATE account SET balance = balance + 50 WHERE id = 1; +-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction +``` + +InnoDB 默认开启死锁检测，发现环后立即回滚其中一个事务（倾向于回滚修改行数少的事务），另一个事务继续执行。上例中事务 2 被回滚，事务 1 提交后余额为 900 和 1100。执行 SHOW ENGINE INNODB STATUS，在 LATEST DETECTED DEADLOCK 一节中可以看到两个事务各自持有和等待的锁。被回滚的事务需要由应用重试。 + +减少数据库死锁的方法： + +- 按相同的顺序访问行，例如转账时先更新 id 小的账户； +- 事务尽量短，不在事务中调用外部接口或等待用户操作； +- 为更新的条件列建立索引，避免扫描时锁住过多的行。 + +## 参考资料 + +- Tanenbaum A S, Bos H. Modern Operating Systems [M]. Pearson, 2014. +- [Deadlocks in InnoDB | MySQL 8.0 Reference Manual](https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlocks.html)