高并发场景下，为什么乐观锁可能不如悲观锁？

在数据库和分布式系统中，处理并发修改数据的问题时，我们通常会用到两种锁机制：乐观锁和悲观锁。两种锁各有优缺点，但在高并发场景下，乐观锁的性能可能不如悲观锁。本文将通过通俗易懂的方式，解释背后的原因。

---

一、什么是乐观锁和悲观锁？

1. 乐观锁（Optimistic Lock）
   乐观锁的核心理念是：“数据一般不会被别人修改，万一被修改了，我就重试。”

   • 实现方式：通过版本号（Version）或时间戳（Timestamp）检测冲突。
   • 操作步骤：
     1. 读取数据时记录版本号。
     2. 修改数据时检查版本号是否变化。
     3. 如果版本号未变，提交修改并更新版本号；如果已变，说明数据被其他人修改过，需要重试。

   适用场景：读多写少，冲突概率低的场景（例如用户信息更新）。

2. 悲观锁（Pessimistic Lock）
   悲观锁的核心理念是：“数据很可能会被别人修改，我先占住它，不让别人动。”

   • 实现方式：通过数据库的行锁（SELECT ... FOR UPDATE）直接锁定数据。
   • 操作步