如何为Hibernate的insert-if-not-exists模式实现多线程处理？

嘿，我明白你要解决的问题了：在多节点部署的应用里，通过getAddressKeyEntity方法，确保每个由address/city/state/zip组成的自然ID，对应唯一的AddressKeyEntity持久化对象，不能出现重复数据对吧？这个场景在分布式系统里很容易踩竞态条件的坑，我来给你拆解下现有代码的问题，再给出靠谱的解决方案。

先说说现有代码的潜在风险 #

你的当前代码用了Hibernate的byNaturalId查询，但如果逻辑是"查不到就插入"的话，在多节点并发请求同一个自然ID时，就会出现问题：两个节点同时查到对象不存在，然后各自插入，最终数据库里就会出现重复的实体。这就是典型的分布式竞态条件。

假设你的完整代码大概是这样：

public AddressKeyEntity getAddressKeyEntity(AddressKeyEntity addressKey) {
    AddressKeyEntity item = sessionFactory.getCurrentSession().byNaturalId(AddressKeyEntity.class)
        .using("address", addressKey.getAddress())
        .using("city", addressKey.getCity())
        .using("state", addressKey.getState())
        .using("zip", addressKey.getZip())
        .load();
    
    if (item == null) {
        item = addressKey;
        sessionFactory.getCurrentSession().save(item);
    }
    return item;
}

这种写法在单节点没问题，但多节点并发时一定会出重复数据。

靠谱的解决方案：多层保障 #

1. 数据库层面：加联合唯一约束（最核心的防线） #

不管代码怎么写，先给数据库表加联合唯一约束，这是防止重复数据的最后一道保险。就算代码层面漏了，数据库也会直接报错阻止插入：

ALTER TABLE address_key_entity 
ADD CONSTRAINT uk_address_city_state_zip 
UNIQUE (address, city, state, zip);

2. Hibernate代码层面：处理并发插入的异常 #

既然数据库会抛唯一约束异常，我们可以利用这个特性，在代码里捕获异常后重新查询已存在的对象。另外，用getReference()代替load()可以延迟插入时机，减少冲突概率：

public AddressKeyEntity getAddressKeyEntity(AddressKeyEntity addressKey) {
    Session session = sessionFactory.getCurrentSession();
    try {
        // 先尝试获取引用，不存在就创建代理对象（不会立即插入）
        AddressKeyEntity item = session.byNaturalId(AddressKeyEntity.class)
            .using("address", addressKey.getAddress())
            .using("city", addressKey.getCity())
            .using("state", addressKey.getState())
            .using("zip", addressKey.getZip())
            .getReference();
        
        // 如果是新代理，设置属性并持久化
        if (!session.contains(item)) {
            item.setAddress(addressKey.getAddress());
            item.setCity(addressKey.getCity());
            item.setState(addressKey.getState());
            item.setZip(addressKey.getZip());
            // 其他属性按需设置
            session.persist(item);
        }
        return item;
    } catch (PersistenceException e) {
        // 捕获唯一约束违反的异常，此时重新查询已存在的对象
        if (e.getCause() instanceof SQLIntegrityConstraintViolationException) {
            return session.byNaturalId(AddressKeyEntity.class)
                .using("address", addressKey.getAddress())
                .using("city", addressKey.getCity())
                .using("state", addressKey.getState())
                .using("zip", addressKey.getZip())
                .load();
        }
        // 其他异常原样抛出
        throw e;
    }
}

这种方式的好处是不用引入额外组件，利用数据库和Hibernate的特性解决问题，性能也不错。

3. 可选：分布式锁（高并发跨节点场景） #

如果你的应用并发量特别高，跨节点的冲突概率很大，可以再加一层分布式锁（比如用Redis或ZooKeeper），确保同一时间只有一个节点能处理某个自然ID的请求：

public AddressKeyEntity getAddressKeyEntity(AddressKeyEntity addressKey) {
    // 用自然ID组合生成唯一的锁key
    String lockKey = String.format("address-lock:%s_%s_%s_%s", 
        addressKey.getAddress(), addressKey.getCity(), 
        addressKey.getState(), addressKey.getZip());
    
    // 假设用Redis分布式锁，这里是伪代码，实际要对应你用的锁组件
    try (RedisLock lock = redisLockProvider.getLock(lockKey)) {
        if (lock.acquire(5, TimeUnit.SECONDS)) { // 5秒超时，可调整
            // 拿到锁后再执行查询/插入逻辑
            Session session = sessionFactory.getCurrentSession();
            AddressKeyEntity item = session.byNaturalId(AddressKeyEntity.class)
                .using("address", addressKey.getAddress())
                .using("city", addressKey.getCity())
                .using("state", addressKey.getState())
                .using("zip", addressKey.getZip())
                .load();
            
            if (item == null) {
                item = addressKey;
                session.save(item);
            }
            return item;
        } else {
            // 获取锁失败，重试或者抛出异常，建议重试几次
            throw new RuntimeException("Failed to acquire lock, please retry later");
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException("Lock operation interrupted", e);
    }
}

这种方式能彻底避免跨节点的竞态条件，但需要额外引入分布式锁组件，增加了系统复杂度，适合高并发场景。

总结一下优先级 #

1. 必做：给数据库加联合唯一约束，这是底线；
2. 推荐：用Hibernate的getReference()+异常捕获的方案，简单有效；
3. 可选：高并发跨节点场景再加分布式锁，进一步降低冲突概率。

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