Hibernate 5+Oracle 12下如何避免重复读取同一实体记录？

你的核心痛点是：并行事务中，被选中的实体依然会被其他事务读取，且无法感知冲突进行重试。结合Oracle 12c和Hibernate 5的特性，我给你两个针对性的解决方案，先分析问题根源，再给出具体实现：

问题根源分析 #

你当前用PESSIMISTIC_READ/WRITE锁生成的SELECT ... FOR UPDATE，在Oracle中只会阻塞其他事务的修改操作，但不会阻止读取——因为Oracle的读一致性机制，其他事务会从undo段读取旧数据。这就导致多个事务能同时读到同一个实体，最后提交的事务会覆盖先提交的修改，且没有任何异常提示，你无法判断哪个事务操作失效。

方案1：用SELECT ... FOR UPDATE SKIP LOCKED（Oracle 12c+专属最优解） #

Oracle 12c引入了SKIP LOCKED语法，它会让查询直接跳过已经被其他事务锁定的行，从根源上避免多个事务选中同一实体。Hibernate 5.2+支持通过锁提示开启这个特性：

// 构建查询并设置悲观写锁 + SKIP LOCKED
Query query = getSession().createQuery("SELECT e FROM Entity e WHERE <CONDITIONS> AND ROWNUM = 1")
    .setLockMode("this", LockMode.PESSIMISTIC_WRITE)
    // 通过Hibernate的锁超时提示启用SKIP LOCKED
    .setHint("javax.persistence.lock.timeout", LockOptions.SKIP_LOCKED);

Optional<Entity> entity = Optional.ofNullable((Entity) query.uniqueResult());

这个方案的优势：

• 其他事务查询时会直接跳过被锁定的实体，不会重复读取
• 不需要重试逻辑，一次查询就能拿到可用的实体（如果存在的话）
• 完全符合你的需求：被读取的实体从其他事务的查询结果中彻底消失

方案2：乐观锁+重试（通用兼容方案） #

如果需要兼容Oracle 12c以下版本，或者不想依赖数据库特定语法，可以用Hibernate的乐观锁机制，通过版本号检测冲突，捕获异常后重试查询：

第一步：给实体添加版本字段 #

@Entity
public class Entity {
    // 其他字段...
    @Version // 乐观锁版本字段，Hibernate会自动维护
    private Long version;

    // getter、setter
}

第二步：修改事务逻辑，捕获冲突并重试 #

public Optional<Entity> pickAndUpdateEntity() {
    int maxRetries = 3; // 自定义最大重试次数
    while (maxRetries-- > 0) {
        try (Session session = factory.openSession()) {
            Transaction tx = session.beginTransaction();
            
            // 查询符合条件的实体
            Query query = session.createQuery("SELECT e FROM Entity e WHERE <CONDITIONS> AND ROWNUM = 1");
            Entity entity = (Entity) query.uniqueResult();
            
            if (entity == null) {
                tx.commit();
                return Optional.empty(); // 没有符合条件的实体
            }
            
            // 修改实体，使其不再满足后续查询条件
            entity.setStatus("USED"); 
            session.update(entity);
            
            tx.commit();
            return Optional.of(entity);
        } catch (OptimisticLockingFailureException e) {
            // 捕获乐观锁冲突异常，说明实体已被其他事务修改，重试查询
            continue;
        } catch (Exception e) {
            e.printStackTrace();
            break;
        }
    }
    return Optional.empty(); // 重试多次后仍失败
}

这个方案的优势：

• 不依赖数据库版本，通用性强
• 通过异常明确感知冲突，触发重试逻辑，确保最终能拿到可用实体

对你实验结果的补充说明 #

你实验中两个事务都能读到实体且无异常，是因为PESSIMISTIC_WRITE只阻塞修改，不阻塞读取。当T1锁定实体后，T2依然能读到undo里的旧数据，直到T1提交后T2的修改才会执行，最后提交的T2覆盖了T1的修改。而用上述两个方案，就能避免这种情况：要么T2跳过锁定行，要么T2修改时抛出异常。

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