Java持久性锁定初学者指南

隐式锁定

在并发理论中，锁定用于保护可变共享数据免受危险数据完整性异常的影响。因为锁管理是一个非常复杂的问题，所以大多数应用程序都依赖于其数据提供程序隐式锁定技术。

将整个锁定职责委托给数据库系统既可以简化应用程序开发，又可以防止诸如死锁之类的并发问题。死锁仍然可能发生，但是数据库可以检测并采取安全措施（任意释放两个竞争锁之一）。

大多数数据库系统使用共享（读取）和排他（写入）锁，这归因于特定的锁定元素（行，表）。尽管SQL标准要求物理锁定，但是悲观的方法可能会阻碍可伸缩性。

现代数据库已实现了轻量级锁定技术，例如多版本并发控制。

隐式数据库锁定隐藏在事务隔离级别配置的后面。每个隔离级别都带有预定义的锁定方案，旨在防止某些数据完整性异常集。

READ COMMITTED对当前事务修改的数据使用查询级共享锁和排他锁。 REPEATABLE READ和SERIALIZABLE在读取时使用事务级共享锁，在写入时使用互斥锁。

如果数据库锁定足以用于批处理系统，则多请求Web流将跨越多个数据库事务。对于长时间的对话，逻辑（乐观）锁定机制更为合适。

与对话级别的可重复读取存储结合使用，乐观锁定可以确保数据完整性，而无需牺牲可伸缩性。

JPA支持开放式锁定和持久性上下文可重复读取，使其非常适合实现逻辑事务。

尽管对于大多数应用程序并发控制要求，隐式锁定可能是最佳选择，但有时您可能需要更细粒度的锁定策略。

大多数数据库系统都支持查询时排他锁定指令，例如SELECT FOR UPDATE或SELECT FOR SHARE 。因此，我们可以使用较低级别的默认隔离级别（READ COMMITTED），同时为特定事务方案请求共享或排他锁。

大多数乐观锁定实现只验证修改后的数据，但是JPA也允许显式乐观锁定。

作为数据库抽象层，JPA可以从基础RDBMS提供的隐式锁定机制中受益。对于逻辑锁定，JPA还提供了可选的自动实体版本控制机制。

JPA支持以下操作的显式锁定：

LockModeType包含以下乐观和悲观锁定模式：

锁定模式类型	描述
没有	在没有显式锁定的情况下，应用程序将使用隐式锁定（乐观或悲观）
乐观的	始终在事务提交时发出版本检查，因此确保乐观锁定可重复读取。
读	与OPTIMISTIC相同。
OPTIMISTIC_FORCE_INCREMENT	始终增加实体版本（即使实体不变），并在事务提交时发出版本检查，从而确保乐观锁定可重复读取。
写	与OPTIMISTIC_FORCE_INCREMENT相同。
PESSIMISTIC_READ	获取共享锁以防止任何其他事务获取PESSIMISTIC_WRITE锁。
PESSIMISTIC_WRITE	获取排他锁以防止任何其他事务获取PESSIMISTIC_READ或PESSIMISTIC_WRITE锁。
PESSIMISTIC_FORCE_INCREMENT	获取数据库锁以防止任何其他事务获取PESSIMISTIC_READ或PESSIMISTIC_WRITE锁，并且在提交事务时会增加实体版本。

JPA 2.0定义了javax.persistence.lock.scope属性，采用以下值之一：

NORMAL由于对象图可以跨越多个表，因此显式的锁定请求可能会传播到多个表（例如，联接继承，辅助表）。由于整个实体关联的行被锁定，因此多对一和一对-一对一的外键也将被锁定，但不会锁定另一侧的父级关联。此范围不会传播到子级集合。
扩展显式锁将传播到元素集合和联结表，但不会锁定实际的子实体。该锁仅在防止幻像读取或更改实际子实体状态的同时，用于防止删除现有子实体时有用。

JPA 2.0还引入了javax.persistence.lock.timeout属性，使我们可以配置在抛出PessimisticLockException之前锁定请求将等待的时间（毫秒）。

Hibernate支持所有JPA锁定模式和一些其他特定的锁定选项。与JPA一样，可以为以下操作配置显式锁定：

LockModeConverter负责映射JPA和Hibernate锁定模式，如下所示：

休眠锁定模式	JPA LockModeType
没有	没有
乐观的读	乐观的
OPTIMISTIC_FORCE_INCREMENT 写	OPTIMISTIC_FORCE_INCREMENT
PESSIMISTIC_READ	PESSIMISTIC_READ
PESSIMISTIC_WRITE 升级 UPGRADE_NOWAIT UPGRADE_SKIPLOCKED	PESSIMISTIC_WRITE
PESSIMISTIC_FORCE_INCREMENT 力	PESSIMISTIC_FORCE_INCREMENT