PostgreSQL乐观锁引发并发更新等待问题咨询

嘿，这个疑惑其实挺典型的，很多刚从悲观锁切换到乐观锁的同学都会碰到，我来给你拆解清楚～

先搞懂两个核心概念的区别 #

首先得明确：JPA的@Version乐观锁是应用层面的校验逻辑，而你看到的更新等待，是PostgreSQL数据库本身的事务隔离机制导致的，这俩完全是两回事！

为什么会出现等待？ #

当你的Spring Boot应用在一个事务中执行更新操作时（哪怕用了乐观锁），PostgreSQL会自动给目标行加上行级排他锁（Row Exclusive Lock），这个锁会一直持有到事务提交或者回滚。这是数据库为了保证事务隔离性（ACID里的I）的默认行为——比如在Repeatable Read（PostgreSQL默认隔离级别）下，要防止其他事务在当前事务未提交时修改同一行数据，避免脏读、不可重复读等问题。

举个具体的场景：

1. 应用A开启事务，加载了某条实体（version=1），然后执行更新语句：

   UPDATE entity SET ..., version=2 WHERE id=? AND version=1;
   

   这时候事务还没提交，PostgreSQL已经给这条行加了排他锁。
2. 这时候你用另一个应用B或者手动执行UPDATE entity SET ... WHERE id=?;，数据库发现目标行已经被加了排他锁，就会让这个更新请求进入等待队列，直到应用A的事务提交/回滚释放锁。

乐观锁到底在干嘛？ #

乐观锁的核心作用是防止“脏写”后的覆盖更新，它不会阻止数据库加锁，而是在更新时校验版本号：

• 如果应用A提交事务后，版本号变成2，这时候应用B如果执行带version=1的更新，会返回0行受影响，JPA会抛出OptimisticLockingFailureException，告诉你更新失败，需要重试。
• 但如果应用B是手动执行不带版本号的更新，那它在锁释放后会直接修改数据，这时候就绕过了乐观锁的校验，这也是为什么我们要求所有更新操作都必须通过JPA的乐观锁机制执行的原因。

总结一下 #

你看到的更新等待，和乐观锁本身无关，是PostgreSQL的事务隔离机制在起作用。乐观锁的价值是在锁释放后，通过版本号校验来避免并发更新导致的数据覆盖，而不是替代数据库的行级锁。如果想要减少这种等待时间，你可以考虑：

• 缩短事务的执行时间，尽快提交/回滚
• 调整数据库的隔离级别（比如降到Read Committed），但这会牺牲部分隔离性，需要根据业务场景权衡
• 优化业务逻辑，尽量减少并发更新同一行的场景

内容的提问来源于stack exchange，提问作者Sel_va