PHP怎么处理Eloquent Locking悲观与乐观锁_Laravel并发控制【技巧】-php教程-PHP中文网

悲观锁selectforupdate()在事务中会阻塞，但仅限数据库行级锁，需db::transaction()包裹且where条件命中索引；乐观锁靠version校验实现无锁并发控制；sharedlock()允许多读但阻塞写，不防丢失更新。

php怎么处理eloquent locking悲观与乐观锁_laravel并发控制【技巧】

悲观锁：selectForUpdate() 在事务中真的会阻塞吗

会，但仅限于数据库层面的行级锁，且必须在事务内生效。脱离 DB::transaction() 或未开启自动提交关闭（PDO::ATTR_AUTOCOMMIT => false）时，selectForUpdate() 可能静默失效或退化为普通查询。

常见错误现象：SQLSTATE[HY000]: General error: 1205 Deadlock found when trying to get lock —— 多个请求同时对同一组记录加锁且顺序不一致，触发 MySQL 死锁。

务必用 DB::transaction() 包裹整个读-改-写流程，不能只给 selectForUpdate() 加事务
锁的范围由 where 条件决定：无索引字段会导致表锁，有复合索引但未覆盖查询条件也会升格为间隙锁
MySQL 中 InnoDB 的 SELECT ... FOR UPDATE 在可重复读（RR）隔离级别下默认加临键锁（Next-Key Lock），可能锁住不存在但“应该存在”的间隙

示例：

DB::transaction(function () {
    $user = User::where('id', 123)->lockForUpdate()->first();
    $user->balance -= 100;
    $user->save();
});

乐观锁：用 increment() 和 where version=xxx 避免覆盖写

乐观锁本质是“先查后验”，不依赖数据库锁机制，靠业务字段（如 version 或 updated_at）做并发校验。Laravel 自带的 increment()、decrement() 是原子操作，但不自带版本检查；需手动拼 where 条件。

容易踩的坑：$model->version++ + $model->save() 不是原子的，两个请求可能读到相同 version，都写入 version=2，丢失一次更新。

正确做法是用 whereRaw('version = ?', [$oldVersion]) 做更新前置校验，再用 update() 一次性完成
若返回影响行数为 0，说明已被其他请求抢先更新，应重试或抛异常
increment() 本身安全，但仅适用于纯数值累加场景（如计数器），无法替代带业务逻辑的“读-改-写”

示例：

$affected = User::where('id', 123)
    ->where('version', $expectedVersion)
    ->update(['balance' => DB::raw('balance - 100'), 'version' => DB::raw('version + 1')]);

selectForUpdate() 和 sharedLock() 的实际区别在哪

selectForUpdate() 加排他锁（X Lock），阻止其他事务读写该行；sharedLock() 加共享锁（S Lock），允许其他事务加 S 锁（即并发读），但会阻塞 X 锁（写操作）。两者都只在事务中有效，且都要求 where 条件命中索引。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

典型误用：sharedLock() 被当成“读不阻塞”的万能方案——但它并不能防止 A 读、B 写、A 再写导致的覆盖问题（即丢失更新），它只防“写-写冲突”，不防“读-写-写”。

想防止别人修改当前行 → 用 selectForUpdate()
只想防止别人修改，但允许多人同时读（比如生成报表前确认数据未被编辑）→ 用 sharedLock()
二者都不解决幻读；如需锁定范围（如“所有 status=0 的订单”），必须配合 WHERE 精确命中索引，否则可能锁表
MySQL 中 sharedLock() 对应 SELECT ... LOCK IN SHARE MODE，注意某些存储引擎（如 MyISAM）不支持

高并发下 update() 带 where 条件为什么有时像乐观锁

因为 InnoDB 的 UPDATE 语句在执行时会先定位记录并加 X 锁，再判断 WHERE 条件是否满足；若不满足，锁会立刻释放。所以多个请求同时执行 User::where('balance', '>=', 100)->decrement('balance', 100)，最终只有第一个成功扣减，其余因条件不满足而跳过——这看起来像乐观锁行为，但底层仍是悲观锁机制。

关键点在于：这不是“无锁重试”，而是“锁了再判，不满足就放”。如果业务需要明确知道是否被抢，不能只靠 affected rows 为 0 就认为失败，得结合具体逻辑判断（比如余额是否真不足）。