本文深入探讨了Spring Data JPA中悲观锁（PESSIMISTIC_WRITE）与PostgreSQL事务隔离级别结合使用时的常见误区。重点解释了为何在PostgreSQL中，将悲观锁与SERIALIZABLE隔离级别同时使用可能导致“could not serialize access”错误而非预期的阻塞行为。文章强调，在大多数场景下，仅使用PESSIMISTIC_WRITE锁即可实现行级阻塞，无需额外提升事务隔离级别，并提供了正确的实践指导。
在并发环境中，为了确保数据的一致性和完整性，数据库锁机制是不可或缺的。Spring Data JPA通过@Lock注解提供了方便的悲观锁（Pessimistic Lock）支持，允许开发者在应用程序层面控制数据库的行级锁定。然而，当悲观锁与特定的数据库事务隔离级别（尤其是PostgreSQL的SERIALIZABLE级别）结合使用时，可能会出现与预期行为不符的情况，例如在并发更新时抛出序列化错误而非阻塞等待。
理解Spring Data JPA的悲观锁
Spring Data JPA的@Lock(LockModeType.PESSIMISTIC_WRITE)注解指示JPA提供者在查询数据时，对查询到的行施加一个排他写锁。对于关系型数据库，这通常会转化为SQL语句中的SELECT ... FOR UPDATE子句。这个锁旨在阻止其他并发事务修改或锁定同一行数据，直到当前事务提交或回滚。
考虑以下一个简单的Repository方法，它尝试更新一个实体的序列号：
import jakarta.persistence.LockModeType;
import jakarta.persistence.EntityManager;
import org.springframework.data.jpa.repository.Lock;
import org.springframework.stereotype.Repository;
@Repository
public class FiveEntityRepository {
private final EntityManager entityManager;
// ... constructor injection
@Lock(LockModeType.PESSIMISTIC_WRITE)
public void addToSequence(Integer id) {
FiveEntity fiveEntity = entityManager.find(FiveEntity.class, id);
if (fiveEntity != null) {
fiveEntity.setSequence(fiveEntity.getSequence() + 1);
// log.debug("sequence: {}", fiveEntity.getSequence()); // For debugging
entityManager.merge(fiveEntity);
}
}
}在这个例子中，当addToSequence方法被调用时，entityManager.find操作会在数据库层面为FiveEntity表中id为指定值的行添加一个写锁。
PostgreSQL中的事务隔离级别：SERIALIZABLE的特殊性
事务隔离级别定义了事务之间相互影响的程度。SERIALIZABLE是最高的隔离级别，旨在确保并发执行的事务产生的结果与这些事务按某种顺序串行执行的结果完全一致。
然而，PostgreSQL实现SERIALIZABLE隔离级别的方式与某些其他数据库系统有所不同。当检测到可能破坏串行性的并发更新或读取模式时，PostgreSQL不会简单地等待锁释放，而是会主动中止其中一个事务并抛出ERROR: could not serialize access due to concurrent update异常。这是PostgreSQL为了保证严格的串行化语义而采取的一种策略，它倾向于通过重试机制来解决冲突，而不是无限期地阻塞。
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
常见的误区：悲观锁与SERIALIZABLE的组合
许多开发者可能会认为，结合使用PESSIMISTIC_WRITE和SERIALIZABLE隔离级别能够提供最强的并发控制和数据一致性。例如，在Service层可能这样定义事务：
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Isolation;
import org.springframework.transaction.annotation.Transactional;
@Service
public class FiveEntityService {
private final FiveEntityRepository fiveEntityRepository;
// ... constructor injection
@Transactional(isolation = Isolation.SERIALIZABLE)
public void processWithPessimisticLock(Integer id) {
fiveEntityRepository.addToSequence(id);
}
}当多个线程或进程尝试并发调用processWithPessimisticLock方法更新同一条记录时，尽管addToSequence方法内部使用了PESSIMISTIC_WRITE锁，但在PostgreSQL环境下，你可能会观察到could not serialize access due to concurrent update的错误，而不是预期的事务阻塞等待。
原因分析： 当第一个事务获取到行锁并开始修改数据时，第二个并发事务在SERIALIZABLE隔离级别下尝试访问或修改同一行。PostgreSQL的SERIALIZABLE机制会检测到这种潜在的冲突，并认为如果允许第二个事务继续执行（即使是等待锁），可能会破坏整体的串行性。因此，它选择抛出异常，要求应用程序层进行重试，而不是让事务阻塞。PESSIMISTIC_WRITE本身会尝试获取锁，但SERIALIZABLE的冲突检测机制优先级更高，导致了异常的发生。
正确实践与建议
对于大多数需要行级阻塞的场景，仅仅使用Spring Data JPA的@Lock(LockModeType.PESSIMISTIC_WRITE)就足够了，并且通常不需要将事务隔离级别提升到SERIALIZABLE。PostgreSQL的默认隔离级别通常是READ_COMMITTED，在这个级别下，SELECT ... FOR UPDATE会按照预期阻塞其他并发事务，直到当前事务释放锁。
推荐的Service层实现：
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.annotation.Isolation; // 可以省略，使用默认隔离级别
@Service
public class FiveEntityService {
private final FiveEntityRepository fiveEntityRepository;
// ... constructor injection
// 推荐做法：移除显式的SERIALIZABLE隔离级别设置
// 此时，事务隔离级别将使用数据库或Spring默认配置（通常是READ_COMMITTED）
@Transactional
public void processWithPessimisticLock(Integer id) {
fiveEntityRepository.addToSequence(id);
}
// 如果确实需要更强的隔离性但又想避免SERIALIZABLE的异常，
// 可以考虑REPEATEABLE_READ（如果数据库支持且符合业务需求）
// 但PESSIMISTIC_WRITE本身已提供强一致性
// @Transactional(isolation = Isolation.REPEATABLE_READ)
// public void processWithPessimisticLockAlternative(Integer id) {
// fiveEntityRepository.addToSequence(id);
// }
}通过移除@Transactional(isolation = Isolation.SERIALIZABLE)，事务将使用默认的隔离级别（例如PostgreSQL的READ_COMMITTED），此时PESSIMISTIC_WRITE将正确地实现阻塞行为，而不是抛出序列化错误。
总结
在使用Spring Data JPA的悲观锁时，务必理解所选数据库的事务隔离级别特性。对于PostgreSQL，SERIALIZABLE隔离级别在检测到并发冲突时会倾向于抛出异常而非阻塞。因此，如果你的目标是实现行级阻塞，通常只需依赖@Lock(LockModeType.PESSIMISTIC_WRITE)，并允许事务运行在默认的（如READ_COMMITTED）隔离级别下。仅当业务逻辑确实需要严格的全局串行化语义，并且应用程序能够优雅地处理SerializationFailureException并实现事务重试机制时，才应考虑使用SERIALIZABLE隔离级别。正确地选择和配置这些机制，是构建健壮、高性能并发应用的关键。
