当前位置：首页 > news >正文

PHP线上死锁的庖丁解牛

news 2026/4/17 19:38:08

它的本质是：两个或多个事务在执行过程中，因争夺资源而造成的一种互相等待 (Circular Wait)的现象。若无外力干涉，它们都将无法推进。在 PHP + MySQL 架构中，这通常不是 PHP 代码本身的逻辑死锁，而是数据库层面（InnoDB 引擎）的行锁/间隙锁冲突，通过 PHP 的事务边界暴露出来。

如果把死锁比作窄桥相遇：

事务 A：占据了桥的左半边，想往右走（请求右半边的锁）。
事务 B：占据了桥的右半边，想往左走（请求左半边的锁）。
结果：谁也动不了，僵持不下。
MySQL 的裁判机制：InnoDB 检测到死锁后，会主动牺牲其中一个事务（通常是代价较小的那个），抛出Deadlock found when trying to get lock异常，让另一个事务继续执行。

一、产生根因：死锁的四个必要条件

只要同时满足以下四个条件，死锁必然发生：

互斥条件 (Mutual Exclusion)：资源（行记录）一次只能被一个事务占用。
持有并等待 (Hold and Wait)：事务 A 持有资源 1，同时申请资源 2。
不可剥夺 (No Preemption)：资源不能被强行抢占，只能由持有者主动释放。
循环等待 (Circular Wait)：A 等 B，B 等 A，形成环路。

💡 核心洞察：在数据库中，我们很难打破前三个条件（这是 ACID 的要求），所以我们主要通过打破“循环等待”来预防死锁——即规定所有事务以相同的顺序访问资源。

二、InnoDB 锁机制：看不见的杀手

PHP 开发者常误以为只有SELECT ... FOR UPDATE才加锁，其实不然。

1. 行锁 (Record Lock)

机制：锁定索引记录。
前提：必须通过索引检索数据。如果没有索引，InnoDB 会退化为表锁，极易导致性能崩溃和死锁。

2. 间隙锁 (Gap Lock)

机制：锁定索引记录之间的“间隙”，防止其他事务插入新记录（解决幻读问题）。
场景：REPEATABLE READ隔离级别下，范围查询（WHERE id > 10）不仅锁住存在的记录，还锁住间隙。
死锁陷阱：两个事务分别锁定不同的间隙，但都想向对方锁定的间隙插入数据，或者更新边界记录，可能形成死锁。

3. 临键锁 (Next-Key Lock)

机制：行锁 + 间隙锁。锁定记录本身及其前面的间隙。
影响：这是 InnoDB 默认的最强锁粒度，也是死锁的高发区。

4. 意向锁 (Intention Lock)

机制：表级锁，表示“我打算给某行加锁”。
作用：提高多粒度锁共存时的效率，通常不直接导致死锁，但参与锁兼容性判断。

三、PHP 触发场景：代码是如何引爆地雷的？

场景 1：经典的 AB-BA 顺序不一致

业务：转账。用户 A 转给用户 B。

线程 1：

DB::beginTransaction();// 1. 锁定 AUser::where('id',1)->lockForUpdate()->first();sleep(1);// 模拟耗时，增加并发碰撞概率// 2. 尝试锁定 B -> 阻塞，因为线程 2 已锁定 BUser::where('id',2)->lockForUpdate()->first();DB::commit();

线程 2：

DB::beginTransaction();// 1. 锁定 BUser::where('id',2)->lockForUpdate()->first();sleep(1);// 2. 尝试锁定 A -> 阻塞，因为线程 1 已锁定 AUser::where('id',1)->lockForUpdate()->first();DB::commit();

结果：死锁。线程 1 等线程 2，线程 2 等线程 1。

场景 2：间隙锁冲突 (Insert Deadlock)

业务：批量插入唯一索引数据。
线程 1：INSERT INTO users (uid) VALUES (10);-> 获取 uid=10 的间隙锁。
线程 2：INSERT INTO users (uid) VALUES (10);-> 也获取 uid=10 的间隙锁（兼容）。
冲突：当两者都试图将间隙锁升级为排他行锁（写入数据）时，发现对方也持有间隙锁，互相等待，形成死锁。

场景 3：索引失效导致锁升级

代码：User::where('name', 'john')->lockForUpdate()->first();
问题：如果name字段没有索引。
后果：InnoDB 扫描全表，对每一行都加上锁。
风险：极大增加锁冲突概率，甚至导致整个表被锁死，其他事务全部阻塞。

场景 4：PHP 事务内调用外部 API

代码：

DB::beginTransaction();$order=Order::find(1)->lockForUpdate();// 锁定订单Http::post('http://external-service/pay');// 远程调用，耗时 5s$order->status='paid';$order->save();DB::commit();

风险：锁持有时间过长（5秒+）。虽然不一定是死锁，但极易引发长时间阻塞，导致后续请求堆积，最终触发数据库连接池耗尽或超时，表现为系统假死。

四、排查与解决：像侦探一样破案

1. 捕捉现场

命令：SHOW ENGINE INNODB STATUS;
关键部分：LATEST DETECTED DEADLOCK。
解读：
- Transaction 1: 正在做什么 SQL，持有什么锁，等待什么锁。
- Transaction 2: 正在做什么 SQL，持有什么锁，等待什么锁。
- Victim: 哪个事务被回滚了。

2. 解决方案

策略 A：固定访问顺序 (Ordering)
- 原则：所有事务必须按照相同的主键/索引顺序访问资源。
- 实施：在转账例子中，始终先锁定 ID 小的用户，再锁定 ID 大的用户。
```
$ids=[$id1,$id2];sort($ids);// 确保顺序一致User::where('id',$ids[0])->lockForUpdate()->first();User::where('id',$ids[1])->lockForUpdate()->first();
```
策略 B：降低隔离级别 (谨慎使用)
- 原理：READ COMMITTED级别下，InnoDB 不使用间隙锁（Gap Lock），只使用行锁。
- 效果：大幅减少死锁概率。
- 代价：可能出现幻读。需评估业务是否允许。
策略 C：优化索引
- 原则：确保WHERE条件和ORDER BY字段都有索引，避免锁升级。
- 行动：EXPLAIN分析 SQL，确保 type 是ref或range，而不是ALL。
策略 D：缩短事务粒度
- 原则：快进快出。
- 行动：
  - 不要在事务中进行 HTTP 请求、复杂计算、文件 IO。
  - 将非数据库操作移到事务外。
  - 尽量一次性批量更新，减少交互次数。

策略 E：重试机制 (Retry)

原理：既然死锁是概率事件，且 InnoDB 会自动回滚其中一个，那么应用层捕获异常并重试即可。
代码：

$maxRetries=3;for($i=0;$i<$maxRetries;$i++){try{DB::transaction(function(){// 业务逻辑});break;// 成功则退出}catch(\Illuminate\Database\QueryException$e){if(strpos($e->getMessage(),'Deadlock')!==false&&$i<$maxRetries-1){continue;// 重试}throw$e;// 其他错误或重试耗尽，抛出}}

🚀 总结：原子化“死锁”全景图

维度	关键点	行动指南
根因	循环等待	固定资源访问顺序
锁类型	行锁、间隙锁、临键锁	理解 RR 级别下的间隙锁行为
索引	无索引导致表锁/全表扫描	确保查询走索引
事务	持有时间过长	事务内禁止 IO/HTTP，快进快出
兜底	死锁不可避免	应用层实现重试机制
监控	`SHOW ENGINE INNODB STATUS`	定期分析死锁日志，优化高频冲突 SQL