MySQL锁机制深度解析：从基础原理到实战应用

前言

锁是数据库实现并发控制的核心技术，用于解决多事务同时操作同一份数据时可能产生的脏读、不可重复读、幻读等事务一致性问题。MySQL的锁体系根据作用范围、粒度和功能划分为多个层级，从覆盖整个数据库实例的全局锁，到控制单张表访问的表级锁，再到精准锁定单行数据的行级锁，不同锁类型适配不同的业务场景，平衡并发性能与数据一致性。本文将从底层原理到实战案例，逐层拆解MySQL锁的核心逻辑，兼顾技术深度与易懂性，帮助你彻底掌握MySQL锁的使用场景与避坑要点。

一、锁的核心概念总览

1.1 锁的本质与核心作用

锁的本质是数据库为协调多线程/多事务并发访问共享资源而实现的同步机制，核心目标是在保障数据一致性、完整性的前提下，尽可能提升系统的并发处理能力。MySQL作为事务型数据库，通过锁机制配合MVCC（多版本并发控制），实现了四种事务隔离级别（读未提交、读已提交、可重复读、串行化），解决了并发场景下的三大数据异常：

脏读：一个事务读取到另一个未提交事务修改的数据
不可重复读：同一事务内两次读取同一行数据，结果因其他事务的提交修改而不一致
幻读：同一事务内两次执行同一范围查询，返回的结果行数因其他事务的插入/删除操作而不同

1.2 MySQL锁的核心分类逻辑

MySQL的锁体系按照锁定粒度从大到小划分为三大类，每一类下又细分不同功能的锁类型，适配不同的业务场景：

锁的层级	锁定范围	并发性能	一致性保障强度	核心适用场景
全局锁	整个数据库所有表	极低	最高	全库一致性备份
表级锁	单张全表/表的元数据/整张表的操作意向	中等	中等	全表批量更新、DDL操作维护元数据一致性
行级锁	单张表内的某一行/某一范围行	极高	灵活可配置	高并发的OLTP业务单行数据操作

二、全局锁：锁定整个数据库的重量级锁

2.1 全局锁的基础介绍

全局锁是MySQL提供的粒度最大的锁类型，执行FLUSH TABLES WITH READ LOCK（简称FTWRL）命令后，会对整个当前连接的数据库实例加锁，加锁后所有的写操作（包括增删改DML、建表改表的DDL、事务提交的写操作）都会被阻塞，仅允许只读操作执行。

全局锁的默认释放逻辑有两种：一是主动执行UNLOCK TABLES命令手动释放；二是当前数据库连接断开，无论主动断开还是异常断开，全局锁都会自动释放，避免数据库长时间不可写。

2.2 全局锁的核心场景：全库一致性数据备份

全局锁最核心、唯一合理的使用场景就是执行全库的一致性物理备份，也就是用mysqldump等工具备份全库所有数据时，必须保证备份出来的所有表的数据是完全一致的时间点切片，否则会出现备份数据的逻辑矛盾。

为什么必须加全局锁才能做一致性备份？

如果不加全局锁直接备份，备份工具会按顺序一张一张表导出数据，假设先导出订单表，再导出用户余额表，在导出订单表之后、导出用户余额表之前，有一个用户下单的事务执行：先扣减用户余额（修改用户表），再新增订单记录（插入订单表），这个事务如果在用户余额表导出前提交，就会导致备份的用户余额已经扣减，但订单表没有对应的新增订单，备份数据出现逻辑不一致，无法用来恢复数据。

加了全局锁之后，所有写操作都被阻塞，备份过程中所有表的数据都不会发生任何修改，备份出来的所有表都是同一个时间点的一致性快照，恢复后的数据逻辑完全正确。

2.3 全局锁的业务风险与替代方案

全局锁的缺陷非常明显：加锁期间整个数据库完全无法写入，对于生产环境的在线业务来说，加全局锁会导致所有写业务直接停摆，除非是从库备份，否则绝对不能在主库执行FTWRL。

针对这个问题，InnoDB存储引擎支持的--single-transaction参数是更优的备份方案，这个参数会让mysqldump在备份前启动一个可重复读隔离级别的事务，利用InnoDB的MVCC机制拿到整个数据库的一致性快照，不需要加任何锁就可以完成一致性备份，整个备份过程完全不阻塞正常的读写操作，是生产环境全库备份的标准方案。只有当你使用的是不支持事务和MVCC的MyISAM存储引擎时，才需要用全局锁来做一致性备份。

三、表级锁：控制单表访问的中粒度锁

表级锁是锁定范围覆盖整张表（或表的元数据）的锁类型，加锁快、无死锁，但并发度低，InnoDB和MyISAM都支持表级锁，MySQL的表级锁细分四类：表锁、元数据锁（MDL）、意向共享锁（IS）、意向排他锁（IX），后两种合称为意向锁。

3.1 表级锁之表锁：最基础的整张表锁定锁

表锁是最古老、最简单的表级锁，和全局锁逻辑类似，只是锁定范围缩小到单张表，手动加锁的语法是LOCK TABLES 表名 READ/WRITE，解锁命令同样是UNLOCK TABLES。

表锁也分为两种类型：

共享表锁（READ锁）：加锁后所有连接只能读这张表，所有写操作都会被阻塞，允许多个连接同时加共享表锁
排他表锁（WRITE锁）：加锁后只有当前连接可以读写这张表，其他所有连接的读写操作都会被阻塞，同一时间只能有一个连接加排他表锁

表锁的适用场景非常少，只有当你需要对一张表执行全表批量更新，且不希望出现行锁冲突、死锁等问题时，才会手动加排他表锁，InnoDB默认不会主动使用表锁，只有在执行DELETE FROM 表名这种无WHERE条件的全表删除时，才会自动升级为表锁，避免加大量行锁带来的性能开销。

3.2 表级锁之元数据锁（MDL）：保障元数据一致性的隐形锁

元数据锁（Metadata Lock，简称MDL）是MySQL 5.5版本引入的核心锁机制，不需要手动加锁，是系统自动维护的锁，核心作用是保障表的元数据（表结构、字段、索引等定义）和数据的一致性，避免在操作表的过程中，表结构被突然修改导致的逻辑错误。

MDL锁的触发逻辑是：只要有任何一个会话正在访问这张表（哪怕是执行一条简单的SELECT查询），就会自动加MDL读锁；只有当需要修改表结构（执行ALTER TABLE、DROP TABLE、RENAME TABLE等DDL操作）时，才会申请加MDL写锁。

MDL锁的互斥规则：MDL读锁之间是兼容的，多个会话可以同时访问同一张表，都加MDL读锁不会冲突；但MDL写锁和所有的MDL读锁、MDL写锁都互斥，也就是说，只要有一个会话的查询还在执行，持有MDL读锁，要修改表结构的DDL语句申请的MDL写锁就会一直等待，而且之后所有新的查询申请MDL读锁，都会排队等在MDL写锁后面，最终导致这张表的所有读写操作全部阻塞，也就是常说的"MDL锁阻塞事故"。

MDL锁的生产避坑要点

生产环境绝对不能在业务高峰执行DDL操作，必须在低峰期先查询processlist和performance_schema.metadata_locks表确认没有长事务持有MDL读锁，再执行DDL；如果必须在线改表，要使用pt-online-schema-change或gh-ost这类无锁改表工具，避免MDL锁阻塞业务。

3.3 表级锁之意向锁：协调表锁与行锁共存的辅助锁

意向锁是InnoDB自动加的、和表级锁配合的辅助锁，存在的核心意义是解决"行锁和表锁冲突检测效率低"的问题，不需要用户手动管理，完全由InnoDB自动维护。意向锁分为两种：

意向共享锁（IS）：当事务要给某一行加行级共享锁（S锁，也就是读锁）之前，必须先给整张表加意向共享锁
意向排他锁（IX）：当事务要给某一行加行级排他锁（X锁，也就是写锁）之前，必须先给整张表加意向排他锁

意向锁的兼容规则

所有意向锁之间都是完全兼容的，也就是多个事务可以同时给同一张表加IS或IX锁，不会互相阻塞；但意向锁和普通的表级锁是互斥的：如果一张表已经有任何事务加了IS或IX锁，那么其他事务要加表级的共享读锁（LOCK TABLES READ）或排他写锁（LOCK TABLES WRITE）都会被阻塞。

为什么需要意向锁？解决的核心痛点是什么

如果没有意向锁，当一个事务要给整张表加排他表锁，就必须扫描整张表的每一行，检查有没有任何行加了行锁，这个操作的时间复杂度是O(n)，表的数据量越大，效率越低；有了意向锁之后，事务要加表级排他锁，只需要检查表上有没有意向锁，只要存在任何意向锁，就说明表里有行正在被修改，直接阻塞即可，时间复杂度是O(1)，效率极高，完美解决了表锁和行锁共存的冲突检测问题。

3.4 意向锁的实战测试：验证锁的兼容性与阻塞逻辑

我们可以通过两个MySQL会话的实操，直观验证意向锁的工作逻辑，所有测试都基于InnoDB存储引擎、可重复读隔离级别：

测试准备

创建一张测试表test_lock，包含id和name两个字段：

sql

CREATE TABLE test_lock (id INT PRIMARY KEY, name VARCHAR(20)) ENGINE=InnoDB;
INSERT INTO test_lock VALUES (1,'张三'),(2,'李四'),(3,'王五');

测试步骤1：行写操作触发意向排他锁

打开会话A，开启事务后执行一行数据的更新，故意不提交事务：

sql

-- 会话A
START TRANSACTION;
UPDATE test_lock SET name='张小三' WHERE id=1;

此时查询InnoDB的锁状态，执行SELECT * FROM performance_schema.data_locks;，可以看到两条锁记录：

表级锁：锁类型是INTENTION_EXCLUSIVE（意向排他锁IX），作用范围是整张test_lock表
行级锁：锁类型是X（排他锁），作用范围是id=1的那一行数据，符合意向锁的加锁规则

测试步骤2：加表锁会被意向锁阻塞

保持会话A的事务不提交，打开会话B，尝试给test_lock加表级共享读锁：

sql

-- 会话B
LOCK TABLES test_lock READ;

执行这条命令后，会话B会直接进入阻塞状态，无法执行成功，这就验证了意向排他锁IX和表级共享读锁是互斥的，符合意向锁的设计逻辑。

测试步骤3：其他事务的行操作不会被意向锁阻塞

再打开会话C，开启事务后修改id=2的行，不需要等待，直接执行成功：

sql

-- 会话C
START TRANSACTION;
UPDATE test_lock SET name='李小四' WHERE id=2;

同样查询锁状态，会看到test_lock表上的IX锁依然存在，同时新增了id=2行的X锁，验证了意向锁之间是完全兼容的，多个事务可以同时给不同的行加行锁，不会互相阻塞，保障了并发性能。

四、行级锁：高并发场景下的核心锁类型

行级锁是InnoDB独有的、粒度最细的锁类型，只会锁定某一行或某一范围的行，是支撑高并发OLTP业务的核心机制，加锁慢、会出现死锁，但并发度极高，是MySQL锁体系中最复杂、最常用的锁类型，行级锁分为三类：行锁（记录锁）、间隙锁、临键锁（Next-Key Lock）。

4.1 行级锁之记录锁（行锁）：精准锁定单行数据的锁

记录锁（Record Lock，也就是常说的行锁）是最基础的行级锁，作用是锁定表中某一行的唯一记录，阻止其他事务修改这一行数据，记录锁分为两种：

共享读锁（S锁）：加锁后当前事务可以读这一行，其他事务可以加S锁读这一行，但不能加X锁修改这一行，加锁语法：SELECT * FROM 表名 LOCK IN SHARE MODE;
排他写锁（X锁）：加锁后当前事务可以读写这一行，其他事务既不能加S锁读，也不能加X锁改，所有的UPDATE、DELETE、INSERT语句都会自动给涉及的行加X锁，普通的SELECT语句不会加任何锁，会走MVCC的一致性读。

记录锁的核心特点是：只有当操作的条件是唯一索引（包括主键索引，主键是特殊的唯一索引），且精准匹配到唯一的一行数据时，InnoDB才会加纯记录锁，不会加其他范围锁，比如UPDATE test_lock SET name='xxx' WHERE id=1，id是主键，匹配唯一一行，就只会给id=1的行加X锁，不会影响其他行的操作。

4.2 行级锁之间隙锁&临键锁（第一部分：核心概念与产生背景）

间隙锁（Gap Lock）和临键锁（Next-Key Lock）是InnoDB为了解决可重复读隔离级别下的幻读问题，专门引入的范围锁类型，这两个锁是很多开发者最容易混淆的知识点，我们拆分来讲解。

什么是幻读？为什么需要专门的锁来解决？

可重复读隔离级别要求，同一个事务内两次读取同一范围的数据，结果必须完全一致，哪怕其他事务提交了修改，也不能影响当前事务的读取结果。如果只有记录锁，会出现幻读问题：

假设test_lock表的id是主键，现有id为1、2、3的三行数据，会话A开启事务后查询id在(0,4)之间的所有数据，拿到三行记录，如果只有记录锁，会话A只会给这三行加行锁，不会锁定中间的空隙；此时会话B插入一条id=4的记录并提交，会话A再次查询同一范围，就会拿到四行记录，出现了幻读，违反了可重复读的隔离要求。

间隙锁就是为了解决这个问题，它会锁定一个范围的空隙，阻止其他事务在这个范围内插入新的数据，从根源上避免幻读。

间隙锁的核心定义

间隙锁是锁定索引记录之间的空隙的锁，InnoDB会把所有的索引记录按顺序排列，记录之间的空隙、第一条记录之前的空隙、最后一条记录之后的空隙都是间隙，InnoDB可以给这些间隙加锁，阻止其他事务在间隙里插入新的记录。

比如刚才的test_lock表，主键id的索引顺序是1、2、3，就会产生四个间隙：(-∞,1)、(1,2)、(2,3)、(3,+∞)，如果事务查询id<4的所有数据，InnoDB会给这四个间隙都加上间隙锁，任何事务都不能在这些间隙里插入新的id，也就无法插入id=4的记录，彻底避免了幻读。

间隙锁的兼容性很特殊：间隙锁和间隙锁之间是完全兼容的，也就是两个事务可以同时给同一个间隙加间隙锁，不会互相阻塞，只有插入操作会和间隙锁冲突，其他的修改、删除操作如果不涉及插入，都不会和间隙锁冲突，这个设计是为了在解决幻读的同时，尽可能提升并发性能。

4.3 行级锁之间隙锁&临键锁（第二部分：临键锁的逻辑与实战测试）

临键锁（Next-Key Lock）是间隙锁+记录锁的组合锁，是InnoDB默认的行锁加锁策略，在可重复读隔离级别下，所有的范围查询（不是精准匹配唯一索引的查询）都会加临键锁，把记录锁和间隙锁结合起来，既锁定已有的记录，也锁定记录之间的间隙，彻底封锁整个范围，阻止任何其他事务在这个范围内插入或修改数据。

临键锁的加锁规则（核心必记）

InnoDB会把索引的所有值划分成若干个左开右闭的区间，作为临键锁的锁定范围，加锁时会给所有匹配到的区间都加上临键锁，具体的加锁场景可以通过实战测试验证：

还是用之前的test_lock表，id是主键，现有数据id=1、2、3，临键锁的默认区间划分是：(-∞,1]、(1,2]、(2,3]、(3,+∞]

测试场景1：范围查询触发临键锁

会话A开启事务，执行范围查询加锁：

sql

-- 会话A
START TRANSACTION;
SELECT * FROM test_lock WHERE id < 3 FOR UPDATE;

FOR UPDATE会给查询结果加排他锁，触发临键锁逻辑。此时查询锁状态：

sql

SELECT OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_DATA
FROM performance_schema.data_locks;

可以看到临键锁锁定了 (-∞,1] 和 (1,2] 两个区间（LOCK_DATA 显示为 1 和 2，LOCK_MODE 为 X），也就是锁住了 id≤2 的所有行以及它们前面的间隙。

此时打开会话B，执行插入测试：

sql

-- 会话B：尝试在锁定区间内插入
INSERT INTO test_lock VALUES (2, '赵六');   -- id=2已存在，主键冲突
-- 更典型的测试：插入一个落在间隙里的值
DELETE FROM test_lock WHERE id = 2;          -- 先删id=2（另一个干净会话中操作）
-- 会话A重新执行 WHERE id < 3 FOR UPDATE 后
-- 会话B执行：
INSERT INTO test_lock VALUES (2, '赵六');   -- 阻塞！id=2落在被锁定的间隙中

会话B的插入会一直等待，直到会话A提交或回滚。而插入 id=5 则可以立即成功，因为它落在 (3,+∞] 区间，不在本次锁定范围内。

测试场景2：精准匹配唯一索引，临键锁退化为记录锁

sql

-- 会话A
START TRANSACTION;
SELECT * FROM test_lock WHERE id = 1 FOR UPDATE;

查询锁状态会发现，这次只给 id=1 这一行加了记录锁（LOCK_MODE 为 X,REC_NOT_GAP），没有加间隙锁。这是 InnoDB 的重要优化：当查询条件是主键或唯一索引的等值匹配，且记录存在时，临键锁退化为纯记录锁，不锁间隙，最大限度保证并发。

测试场景3：非唯一索引的范围查询，临键锁不退化

如果查询条件走的是普通索引（非唯一），即使是等值查询，也会加临键锁锁定间隙。这解释了为什么"给高频更新字段建唯一索引"不仅能保证数据正确性，还能减少锁冲突。

4.4 行级锁之死锁：成因、排查与规避

什么是死锁

死锁是两个或多个事务互相持有对方需要的锁，形成循环等待，谁也无法继续执行的僵局：

事务A：锁住行1 → 请求锁行2（等待）
事务B：锁住行2 → 请求锁行1（等待）
→ 互相等待，形成死环

InnoDB 内置死锁检测机制，发现死锁后会主动回滚代价较小的事务（通常是修改行数少的那个），让另一个事务继续执行。被回滚的事务会收到 ERROR 1213: Deadlock found when trying to get lock 错误。

死锁复现实验

sql

-- 会话A                           -- 会话B
START TRANSACTION;                 START TRANSACTION;
UPDATE test_lock SET name='A1' WHERE id=1;
                                   UPDATE test_lock SET name='B2' WHERE id=2;
UPDATE test_lock SET name='A2' WHERE id=2;   -- 等待B释放id=2
                                   UPDATE test_lock SET name='B1' WHERE id=1;
                                   -- 等待A释放id=1 → 死锁！
                                   -- InnoDB 检测到死锁，回滚其中一个事务

死锁排查方法

sql

-- 查看最近一次死锁的完整信息（含两个事务各自执行的SQL）
SHOW ENGINE INNODB STATUS;
-- 关注输出中的 "LATEST DETECTED DEADLOCK" 段落

-- 开启死锁日志，把所有死锁记录到错误日志（生产建议开启）
SET GLOBAL innodb_print_all_deadlocks = ON;

-- 查看当前正在等待锁的事务
SELECT * FROM performance_schema.data_lock_waits;

死锁的规避原则

固定加锁顺序：所有事务按相同的顺序访问多张表/多行数据（如统一按主键从小到大），消除循环等待的可能；
缩短事务：事务越短，持锁时间越短，死锁概率越低；把非数据库操作挪出事务；
降低隔离级别：读已提交（RC）不产生间隙锁，死锁概率大幅降低（需评估业务对幻读的容忍度）；
批量操作拆分：一次 UPDATE 几千行容易与其他事务交错产生死锁，分批执行；
为 WHERE 条件建索引：无索引的更新会锁全表所有行（临键锁锁所有区间），死锁概率飙升。

五、锁机制的实战应用与优化建议

5.1 不同隔离级别下的锁行为差异

隔离级别	间隙锁/临键锁	幻读防护方式	并发性能	适用场景
读未提交（RU）	无	无防护	最高	几乎不用
读已提交（RC）	无	无防护（接受幻读）	高	大多数互联网业务
可重复读（RR，默认）	有	间隙锁 + MVCC	中	金融、账务类强一致场景
串行化	所有读都加锁	完全串行	最低	几乎不用

5.2 生产环境锁优化清单

所有 UPDATE/DELETE 的 WHERE 必须走索引：这是行锁时代的第一铁律，无索引更新等于锁全表；
优先使用唯一索引做等值更新：触发临键锁退化为记录锁，并发度最高；
控制单次事务的修改行数：大批量更新分批执行，每批几百到几千行；
避免长事务：用 information_schema.innodb_trx 定期巡检超过 60 秒的事务；
合理设置锁等待超时：innodb_lock_wait_timeout 默认 50 秒太长，高并发业务建议设为 3~10 秒，让冲突快速失败重试；
读多写少场景用普通 SELECT：普通读走 MVCC 快照不加锁，只有需要"读取后修改"的场景才用 FOR UPDATE；
警惕 SELECT ... FOR UPDATE 的范围：范围条件会加临键锁封锁整个区间，能用等值就不用范围。

5.3 锁问题的排查工具箱

sql

-- 1. 看当前所有锁
SELECT * FROM performance_schema.data_locks;

-- 2. 看锁等待关系（谁在等谁）
SELECT * FROM performance_schema.data_lock_waits;

-- 3. 看正在运行的事务及持锁时长
SELECT trx_id, trx_state, trx_started, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

-- 4. 看 MDL 锁（DDL 被阻塞时查这个）
SELECT * FROM performance_schema.metadata_locks;

-- 5. 看最近一次死锁详情
SHOW ENGINE INNODB STATUS;

-- 6. 定位到问题会话后终止
KILL <process_id>;

六、总结

MySQL 锁体系的核心逻辑可以归纳为三条主线：

按粒度选锁：全局锁只做备份（且优先用 --single-transaction 替代），表级锁中的 MDL 是 DDL 安全的隐形守护者，意向锁是表锁与行锁共存的高效协调器，行级锁是高并发业务的主力；
行锁三兄弟各司其职：记录锁管单行、间隙锁管空隙防幻读、临键锁是二者组合也是 RR 级别的默认策略；唯一索引等值匹配时临键锁退化为记录锁，是最重要的优化点；
死锁不可怕，无备才可怕：死锁是并发系统的正常现象，InnoDB 会自动检测并回滚；真正要做的是规范加锁顺序、缩短事务、保证更新走索引，并用 performance_schema 工具箱建立日常巡检机制。

锁的本质是在一致性与并发度之间寻找平衡点。理解了每层锁"锁什么、什么时候加、什么时候放"，你就能在业务设计阶段就规避掉绝大多数锁问题，而不是等线上事故发生了再补课。

MySQL锁机制深度解析：从基础原理到实战应用 ​

前言 ​

一、锁的核心概念总览 ​

1.1 锁的本质与核心作用 ​

1.2 MySQL锁的核心分类逻辑 ​

二、全局锁：锁定整个数据库的重量级锁 ​

2.1 全局锁的基础介绍 ​

2.2 全局锁的核心场景：全库一致性数据备份 ​

为什么必须加全局锁才能做一致性备份？ ​

2.3 全局锁的业务风险与替代方案 ​

三、表级锁：控制单表访问的中粒度锁 ​

3.1 表级锁之表锁：最基础的整张表锁定锁 ​

3.2 表级锁之元数据锁（MDL）：保障元数据一致性的隐形锁 ​

MDL锁的生产避坑要点 ​

3.3 表级锁之意向锁：协调表锁与行锁共存的辅助锁 ​

意向锁的兼容规则 ​

为什么需要意向锁？解决的核心痛点是什么 ​

3.4 意向锁的实战测试：验证锁的兼容性与阻塞逻辑 ​

测试准备 ​

测试步骤1：行写操作触发意向排他锁 ​

测试步骤2：加表锁会被意向锁阻塞 ​

测试步骤3：其他事务的行操作不会被意向锁阻塞 ​

四、行级锁：高并发场景下的核心锁类型 ​

4.1 行级锁之记录锁（行锁）：精准锁定单行数据的锁 ​

4.2 行级锁之间隙锁&临键锁（第一部分：核心概念与产生背景） ​

什么是幻读？为什么需要专门的锁来解决？ ​

间隙锁的核心定义 ​

4.3 行级锁之间隙锁&临键锁（第二部分：临键锁的逻辑与实战测试） ​

临键锁的加锁规则（核心必记） ​

测试场景1：范围查询触发临键锁 ​

测试场景2：精准匹配唯一索引，临键锁退化为记录锁 ​

测试场景3：非唯一索引的范围查询，临键锁不退化 ​

4.4 行级锁之死锁：成因、排查与规避 ​

什么是死锁 ​

死锁复现实验 ​

死锁排查方法 ​

死锁的规避原则 ​

五、锁机制的实战应用与优化建议 ​

5.1 不同隔离级别下的锁行为差异 ​

5.2 生产环境锁优化清单 ​

5.3 锁问题的排查工具箱 ​

六、总结 ​