章
目
录
在面试时，经常会被问到为什么不建议用悲观锁，悲观锁有哪些缺点之类的问题。本文将深入探讨不推荐使用悲观锁的原因，同时也会提及适合使用悲观锁的特定场景，帮助大家更好地理解和运用这一概念。
一、悲观锁的基本概念回顾
在上一篇面试题中，我们已经了解过悲观锁的概念。简单来说，悲观锁秉持着一种“悲观”的态度，它假定每次事务操作都极有可能修改同一资源。为了避免并发操作带来的数据不一致问题，就必须对资源加锁。在SQL层面，实现悲观锁的常用方式是 select for update 语句，这条语句会锁定查询结果中的记录，确保同一时刻只有一个事务能够对这些记录进行修改操作。
二、不推荐使用悲观锁的原因
1）性能瓶颈：使用悲观锁会带来一系列性能问题。每次操作都需要加锁和释放锁，这一过程会产生额外的开销。而且，同一时间只有一个事务可以修改数据，其他事务只能处于阻塞等待状态。数据库连接资源是有限的，大量事务长时间等待锁的释放，会导致数据库连接被长时间占用。这会使得其他线程无法获取数据库连接，进而造成应用层的连接超时，比如网关层和负载均衡层的连接都可能出现超时情况。这种情况一旦发生，就会引发“惊群效应”，导致整个平台出现超时现象，数据库也会频繁报错，产生大量慢SQL，严重影响系统的性能和稳定性。
2）锁升级与死锁风险：悲观锁通常是基于数据库索引加的行锁，但如果出现索引失效的情况，比如查询条件未命中索引，或者有些粗心的开发者忘记添加索引，原本的行锁就可能会升级为表锁，将整个表锁住。在涉及多个表的关联查询时，这种表锁的情况很容易引发死锁。一旦出现死锁，如果没有外界干预，相关事务会一直处于锁定状态，导致系统部分功能无法正常运行。
三、悲观锁的适用场景
虽然悲观锁存在诸多弊端，但在某些特定场景下，它还是有其用武之地的。在对数据一致性要求极高，且并发量不高的场景中，悲观锁是个不错的选择。例如金融类的账户处理场景，每一笔资金的变动都必须保证准确无误，不允许出现数据不一致的情况。再比如库存扣减场景，在并发量不大时，使用悲观锁可以确保库存数量的准确性，避免超卖等问题。
悲观锁并非一无是处，但它的局限性确实较为明显。在大多数情况下，尤其是并发量大、读多写少的场景中，使用悲观锁可能会带来性能灾难。我们在实际开发中，需要根据具体的业务场景和需求，谨慎选择是否使用悲观锁。如果大家对悲观锁还有其他疑问或者不同的看法，欢迎在评论区留言讨论，咱们一起交流学习！
