Hibernate乐观锁在不同JVM环境下是否无法正常工作？

首先明确：Hibernate乐观锁完全支持跨JVM/多独立服务场景，它的生效逻辑依赖数据库层面的版本校验，和服务运行在哪个JVM无关。你遇到的跨服务更新互相覆盖问题，本质是乐观锁的使用方式有误，而非机制本身不支持跨JVM。

乐观锁的核心原理 #

乐观锁通过实体类上的@Version注解标记版本字段（通常是Integer、Long类型，也可用Timestamp）实现。每次更新实体时，Hibernate会自动生成带版本条件的SQL：

UPDATE account SET balance = ?, version = version + 1 WHERE id = ? AND version = ?

无论请求来自同一个JVM还是不同JVM，只要更新时携带的版本值与数据库当前版本不匹配，数据库会返回0行更新，Hibernate随即抛出OptimisticLockingFailureException，阻止脏更新。

你的场景中可能存在的问题 #

既然单服务多线程下乐观锁生效，说明@Version注解的基础配置是正确的。跨服务失效大概率是以下原因：

1. 使用批量JPQL/SQL更新而非实体托管更新 #

如果accountUpdate、accountNetTotalsUpdate等方法中，使用了手动编写的JPQL/SQL批量更新（比如直接写UPDATE Account SET balance = ? WHERE id = ?），而不是先加载实体、修改属性、由Hibernate自动生成带版本条件的更新语句，乐观锁会直接失效。

这种情况下，必须手动在JPQL中加入版本校验和递增逻辑：

@Modifying
@Query("UPDATE Account a SET a.balance = :balance, a.version = a.version + 1 WHERE a.id = :id AND a.version = :version")
void updateAccountBalance(@Param("id") Long id, @Param("balance") BigDecimal balance, @Param("version") Integer version);

2. 事务内持有旧版本实体 #

如果在balancesAndAmtsUpdate方法中，过早加载Account实体（比如mapTransactionsToAccounts阶段），之后执行了大量耗时的分组、聚合操作，这期间其他服务可能已经更新了该Account的版本。当当前事务最终更新实体时，使用的还是旧版本值，此时会触发乐观锁异常，但如果异常被内部代码捕获吃掉，就不会触发重试逻辑，导致更新覆盖。

3. 版本字段类型选择不当 #

如果使用Timestamp作为版本字段，不同JVM的系统时间精度差异可能导致版本校验失效。建议改用Integer或Long类型的版本字段，逻辑更稳定可靠。

4. 异常捕获逻辑问题 #

你的方法标注了@Retryable(value = {Exception.class})，理论上能捕获OptimisticLockingFailureException（RuntimeException的子类），但如果在accountUpdate等内部方法中，将该异常捕获并处理（比如返回错误码而非抛出），就会导致重试逻辑无法触发，脏更新无法被阻止。

修复建议 #

1. 统一更新方式：所有Account的更新操作，都通过「加载最新实体→修改属性→提交事务」的方式执行，依赖Hibernate自动生成带版本条件的SQL，避免手动写JPQL/SQL更新。
2. 延迟实体加载：尽量在即将更新前才加载Account实体，减少事务内持有旧版本的时间窗口。
3. 检查异常链路：确保OptimisticLockingFailureException能被抛到balancesAndAmtsUpdate方法层级，触发重试机制。
4. 更换版本字段类型：将Timestamp类型的版本字段改为Integer或Long，避免时间精度问题。

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