原文地址

为了能够同步访问实体，JPA提供了2种锁机制。这两种机制都可以避免两个事务中的其中一个，在不知情的情况下覆盖另一个事务的数据。

通过实体锁，我们通常希望避免在两个并行事务中产生如下情形：

1. Adam的事务读取数据 X
2. Barbara的事务读取数据 X
3. Adam的事务修改数据 X，并将其修改为 XA
4. Adam的事务写入数据 XA
5. Barbara的事务修改数据 X，并将其修改为 XB
6. Barbara的事务写入数据 XB

结果是，Adam所做的修改完全被Barbara所覆盖掉了，但是Barbara对此却毫不知晓。像这样的情况通常被称为“脏读”。显然，我们希望的结果是Adam写入 XA，而Barbara需要在写入 XB之前检查对 XA 的修改。

乐观锁的工作原理

乐观锁基于的假设是实际中冲突很少发生，即使发生，抛出一个错误也比想办法避免它们更容易接受和简单。在乐观锁中，允许一个事务正确完成，但另一个事务需要抛出异常并回滚，并且必须被重新执行或者丢弃。

我们还以Adam和Barbara为例，下面是一个使用乐观锁可能发生的情形：

1. Adam的事务读取数据 X
2. Barbara的事务读取数据 X
3. Adam的事务修改数据 X，并将其修改为 XA
4. Adam的事务写入数据 XA
5. Barbara的事务修改数据 X，并将其修改为 XB
6. Barbara的事务试图写入数据 XB，但是收到一个错误
7. Barbara需要读取数据 XA（或者重新开始一个新的事务）
8. Barbara的事务修改数据 XA，并将其修改为 XAB
9. Barbara的事务写入数据 XAB

如你所见，Barbara被强制要求检查Adam的修改，并且她可以选择继续修改Adam的结果并保存（合并修改）。最后的数据将同时包括Adam和Barbara的修改。

乐观锁完全由JPA控制。它需要在DB表中额外存储一个版本号列。它完全依靠于底层用来存储关系型数据的DB引擎来工作。

悲观锁的工作原理

对于某些人来说，悲观锁更容易接受。当事务需要修改一个可能被其他事务同时修改的实体时，事务会发起一个命令将实体锁住。所有的锁会持续到事务结束后再自动释放。

使用悲观锁的情形可能如下所示：

1. Adam的事务读取数据 X
2. Adam的事务锁住 X
3. Barbara的事务希望读取数据 X，但是因为 X 已经被锁住，只好等待
4. Adam的事务修改数据 X，并将其修改为 XA
5. Adam的事务写入数据 XA
6. Barbara的事务读取数据 XA
7. Barbara的事务修改数据 XA，并将其修改为 XAB
8. Barbara的事务写入数据 XAB

如你所见，Barbara又一次被强制的写入 XAB，同时也包含了Adam的修改。但是，这个方案与乐观锁完全不同——Barbara需要等待Adam的事务完成以后才能够读取数据。更甚的是，为了让该场景正确工作，我们需要在两个事务中都手动发起一个lock命令。（因为我们并不确定那个事务先运行，所以两个事务都需要在修改数据前先进行锁定）虽然乐观锁要为每个实体增加一个版本列，比悲观锁工作略多，但是之后我们不需要再在事务中发起锁操作了。JPA会自动完成所有的检查，我们只需要处理可能的异常即可。

悲观锁使用底层数据库提供的锁机制来锁住表中已有的记录。JPA需要知道如何触发这些锁，并且尚不能完全支持某些数据库。

即使是JPA规范中也说到，不需要提供PESSIMISTIC_READ（因为许多DB只支持WRITE锁）：

允许JPA实现用LockModeType.PESSIMISTIC_WRITE来代替LockModeType.PESSIMISTIC_READ，但是反之不可。

JPA中可用的锁类型

首先，我想说，对于实体中有添加了@Version注解的列，JPA会自动对该实体使用乐观锁。你不需要使用任何锁命令。但是，你可以在任何时候发起一个以下类型的锁：

1. LockModeType.Optimistic
   1. 这就是默认的锁类型。也是如ObjectDB所说通常被大家所忽略的锁类型。在我的印象中，只有在需要动态获取并传递锁类型时，才会用到它，即使我们很清楚最后的锁是OPTIMISTIC的。虽然这个例子不太恰当，但是一个好的API设计，即使是默认值也应该为其提供一个可选项。
   2. 示例：Java

LockModeType lockMode = resolveLockMode();
A a = em.find(A.class, 1, lockMode);

2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

   1. 这个选项很少被用到。但是如果你希望用另一个实体来锁住对当前实体的引用，就需要使用它。换句话说，即使当前实体没有被修改，但是其他实体可能因为当前实体被修改，你就可以用它来锁住对当前实体的引用。
   2. 示例：
      1. 假设我们有两个实体“书（Book）”和“书架（Shelf）”。我们可以将书添加到书架中，但是书不持有对其书架的引用。我们需要对所有移动书到其他书架的动作加锁，以避免一本书被放在2个书架上。为了锁住这个动作，光锁住当前的书架实体是不够的，因为书可能还没有放到某个书架上。锁住所有书架也不合理，因为他们在不同的事务中可能都是不同的。唯一合理的是锁住书实体本身，即使在我们这个例子中它并没有发生变化（因为它并不持有其书架的引用）。

3. LockModeType.PESSIMISTIC_READ

   1. 这个模式类似于LockModeType.PESSIMISTIC_WRITE，但是有一点不同：如果没有事务对实体加写锁，那么就不能阻塞对该实体的读取。它还允许其他事务使用LockModeType.PESSIMISTIC_READ来加锁。WRITE锁和READ锁之间的区别，已经被这两篇文章（here (ObjectDB) 和 here (OpenJPA)）很详细的说明了。但是，不仅因为规范中允许，而且许多实现也没有分开处理，所以该锁模式经常被等价于LockModeType.PESSIMISTIC_WRITE。

4. LockModeType.PESSIMISTIC_WRITE

   1. 这是LockModeType.PESSIMISTIC_READ的增强版。当WRITE锁发生时，JPA在数据库的帮助下，会阻止其他事务读取实体，而不像READ锁那样只禁止写入。

5. LockModeType.PESSIMISTIC_FORCE_INCREMENT

   1. 这是另一个很少使用的锁模式。但是，它可以用来结合PESSIMISTIC和OPTIMISTIC时使用。在以下场景中，单独使用PESSIMISTIC_WRITE是无效的：

      1. 事务A使用乐观锁并读取实体E
      2. 事务B请求实体E上的WRITE锁
      3. 事务B提交并释放E上的锁
      4. 事务A更新E并提交

   2. 在步骤4中，如果事务B没有增加版本列的值，那么就无法阻止事务A覆盖B的修改。即使事务B使用的是悲观锁，锁模式LockModeType.PESSIMISTIC_FORCE_INCREMENT也会强制事务B更新版本号，并让事务A失败并抛出OptimisticLockException。

为了发起一个指定类型的锁，JPA提供了以下方法：

• 某些EntityManager方法接收一个指定锁类型的可选参数，例如

  • find(Class entityClass, Object primaryKey, LockModeType lockMode)
  • lock(Object entity, LockModeType lockMode)
  • 以及其他从DB获取数据的方法，例如merge()或者refresh()

• JPA的Query接口还提供了setLockMode(LockModeType lockMode)方法来锁住所有通过查询获取的实体

你可以使用JPA中这两种锁机制中的任意一种。如果需要，也可以选择悲观锁类型PESSIMISTIC_FORCE_INCREMENT，把二者混起来用。

• 要想了解更多，请阅读Vlad Mihalcea. 的精彩博客。

欢迎打赏（微信请点击“阅读原文”），也请关注微信公众账号“重度恐高症”，精彩技术文章就在这里。