thinkphp悲观锁核心作用是保证并发下数据一致性，避免超卖等错误；2. 实现方式是在事务中用lock(true)或forupdate()锁定行，直到事务提交；3. 避免死锁需按固定顺序加锁、缩短事务时间、捕获异常回滚；4. 性能影响包括降低并发和增加等待，高并发写或非强一致场景应慎用。
在ThinkPHP中，要实现悲观锁并锁定数据行，核心思路是利用数据库的行级锁定机制，确保在并发操作下，特定数据行的读写操作是串行的，从而维护数据的一致性。简单来说，就是告诉数据库：“嘿，这行数据我要操作了，别人暂时别碰！”
解决方案
说实话，在ThinkPHP里用悲观锁，最直接、最常用的方式就是结合数据库的事务，然后在使用查询方法时加上lock(true)或forUpdate()。这背后其实是sql的select … FOR UPDATE语句，它会给查询到的行加上排他锁，直到事务提交或回滚。
具体操作流程大概是这样：
立即学习“PHP免费学习笔记（深入）”；
-
开启事务： 悲观锁必须在事务中才能发挥作用。没有事务，锁会在语句执行完后立即释放，那就没意义了。
Db::startTrans();
-
查询并锁定： 在查询数据时，加上锁定指令。
try { // 假设我们要锁定id为1的用户余额 $user = Db::name('user') ->where('id', 1) ->lock(true) // 或者 forUpdate()，效果类似 ->find(); if (!$user) { // 用户不存在，直接回滚 Db::rollback(); return '用户不存在'; } // 模拟业务逻辑：扣减余额 if ($user['balance'] < 100) { Db::rollback(); return '余额不足'; } $newBalance = $user['balance'] - 100; Db::name('user') ->where('id', 1) ->update(['balance' => $newBalance]); // 提交事务 Db::commit(); return '扣款成功，新余额：' . $newBalance; } catch (Exception $e) { // 发生异常，回滚事务 Db::rollback(); return '操作失败：' . $e->getMessage(); }
这里lock(true)或forUpdate()就起到了关键作用，它会告诉数据库，当前事务要独占这些行，其他事务如果也想修改或加锁这些行，就得等着。
ThinkPHP悲观锁在并发场景下的核心作用是什么？
嗯，悲观锁在并发场景下的核心作用，说白了就是保证数据的一致性和完整性，避免脏读、不可重复读和幻读。想象一下，一个电商系统，用户A和用户B同时购买同一件库存只剩一件的商品。如果没有锁机制，可能出现的情况是：
- 用户A查询商品库存，显示为1。
- 用户B查询商品库存，也显示为1。
- 用户A扣减库存，更新为0。
- 用户B也扣减库存，也更新为0。
结果就是，一件商品被卖了两次，库存变成了负数，这显然是灾难性的。
悲观锁的介入，就像在商品库存这行数据上设了个“红绿灯”。当用户A去查询并准备修改时，它会给这行数据上锁，变成“红灯”。这时，用户B再来查询并尝试修改，就会被“红灯”拦住，要么等待用户A操作完成并释放锁，要么根据配置直接报错。这样一来，就确保了同一时间只有一个事务能够修改这行数据，从而保证了库存的准确性，避免了超卖。它牺牲了一定的并发性，来换取绝对的数据安全性，这对于金融交易、库存管理等对数据一致性要求极高的场景来说，是不可或缺的。
如何避免ThinkPHP悲观锁可能导致的死锁问题？
死锁，这玩意儿是悲观锁的“副作用”之一，也是最让人头疼的问题。它发生在两个或多个事务互相等待对方释放锁资源时。比如，事务A锁定了表X的行1，想去锁表Y的行1；同时，事务B锁定了表Y的行1，想去锁表X的行1。大家都不放手，就僵住了。
避免死锁，我觉得有几个策略是比较有效的：
-
保持锁的顺序一致： 这是最关键的。如果你的事务需要锁定多行或多张表的资源，那么所有相关的事务都应该按照相同的顺序去获取这些锁。比如，总是先锁用户表，再锁订单表。
// 假设场景：用户A给用户B转账，需要锁定A和B的账户 // 错误的顺序（可能导致死锁）： // 事务1：先锁A，再锁B // 事务2：先锁B，再锁A // 正确的顺序（比如按ID从小到大锁定）： Db::startTrans(); try { $id1 = min($userIdA, $userIdB); $id2 = max($userIdA, $userIdB); $user1 = Db::name('user')->where('id', $id1)->lock(true)->find(); $user2 = Db::name('user')->where('id', $id2)->lock(true)->find(); // ... 业务逻辑 ... Db::commit(); } catch (Exception $e) { Db::rollback(); } -
缩短事务和锁的持有时间： 事务越短，锁被持有的时间就越短，发生死锁的几率就越小。尽量只在需要锁定数据的时候才开启事务和加锁，操作完成后立即提交或回滚。
-
使用try-catch捕获异常并回滚： 虽然不能直接“避免”死锁发生，但当死锁发生时（数据库通常会检测到并选择一个事务作为“牺牲品”回滚），你的代码能够优雅地处理，比如重试。ThinkPHP的事务管理本身就支持异常捕获。
-
审慎使用，评估替代方案： 有时候，悲观锁并不是唯一的选择。对于某些场景，乐观锁（通过版本号或时间戳来判断冲突）可能更合适，因为它不会阻塞并发操作。
ThinkPHP悲观锁对数据库性能有什么影响，以及何时应该谨慎使用？
悲观锁对数据库性能的影响是显而易见的，它主要体现在降低并发性和增加等待时间上。
- 并发性降低： 当一个事务锁定了某些数据行时，其他需要访问这些行的事务就必须等待。如果锁定的行是高频访问的热点数据，那么等待的事务就会排起长队，系统吞吐量自然就下来了。
- 资源争用： 数据库需要花费额外的资源来管理和检测锁，这也会增加数据库的负担。
- 死锁风险： 前面提到了，死锁一旦发生，会造成事务回滚，不仅影响用户体验，也浪费了数据库资源。
所以，何时应该谨慎使用悲观锁呢？我觉得有以下几个场景：
- 高并发写入场景： 如果你的系统每秒有成百上千次对同一批数据的写入操作，那么频繁使用悲观锁很可能会成为性能瓶颈。
- 读多写少，且对数据一致性要求非极致的场景： 比如一个文章阅读量计数，偶尔的误差是可以接受的，用悲观锁就有点“杀鸡用牛刀”了。这种情况下，乐观锁或者直接让数据库自己处理并发更新（如果业务允许少量数据丢失）可能更合适。
- 锁定的范围过大： 如果你因为查询条件不精确，导致锁定了大量不必要的行，那影响就更大了。确保你的WHERE条件是精准的，只锁定真正需要操作的行。
我的建议是，在设计系统时，首先考虑业务对数据一致性的要求。如果业务场景对数据一致性要求非常高，比如银行转账、库存扣减，那么悲观锁是保障数据安全的重要手段。但如果一致性要求不是那么严格，或者并发量特别大，可以优先考虑乐观锁，或者结合消息队列、分布式事务等其他技术方案来解决并发问题，将悲观锁作为最后的、最严格的保障手段。毕竟，性能和一致性之间，很多时候需要找到一个平衡点。
