如何用Spring Data JPA CRUD方法实现原子性“不存在则保存”逻辑？

1. 仅添加@Transactional注解不能解决该问题 #

@Transactional仅能将查询和保存操作包裹在同一个事务中，并没有改变「先查后插」的执行逻辑，在常规的事务隔离级别（如MySQL默认的REPEATABLE READ）下，无法阻止两个并发事务同时通过用户名存在性校验，先后执行插入操作时仍会触发唯一约束冲突。
即便将事务隔离级别调整为SERIALIZABLE来避免该问题，也会带来极大的性能损耗，完全不适合用户注册这类高并发的公开场景。

2. 正确的解决方法 #

首先明确前提：无论采用哪种上层优化方案，必须先在数据库层面为username字段添加唯一约束，这是保证数据正确性的最后一道防线。
常用的可行方案如下：

• 方案一：捕获DataIntegrityViolationException做兼容处理
  这是成本最低、适配性最高的方案，提前的存在性查询可以拦截绝大多数重复注册请求，仅极端并发场景下的冲突会落到异常分支处理，兼顾性能和正确性。修改后的代码参考如下：

@PostMapping
public String processRegistrationForm(@Valid @ModelAttribute("registrationForm") UserForm form,
                                      Errors errors, Model model) {
    if (errors.hasErrors()) {
        return "registration";
    }
    // 提前校验拦截绝大多数重复请求
    UserEntity user = usersRepository.findByUsername(form.getUsername());
    if (user != null) {
        errors.rejectValue("username", "registration.username.not.unique");
        return "registration";
    }
    try {
        usersRepository.save(form.toUserEntity(passwordEncoder));
        model.addAttribute("isRegistrationComplete", true);
    } catch (DataIntegrityViolationException e) {
        // 捕获唯一约束冲突，返回重复提示
        errors.rejectValue("username", "registration.username.not.unique");
    }
    return "registration";
}

• 方案二：新增分布式锁做前置控制
  若业务场景不希望依赖数据库异常处理，可以在执行用户名查询前，针对当前请求的username加分布式锁（比如基于Redis的SETNX实现），同一时间只有一个请求能处理同一个用户名的注册逻辑，保存操作完成后再释放锁。该方案可以避免冲突请求打到数据库层，但需要额外引入分布式锁组件，同时要做好锁过期时间、死锁兜底等逻辑处理。
• 方案三：使用数据库自定义插入语句
  可以直接编写支持冲突处理的插入SQL，比如MySQL的INSERT ... ON DUPLICATE KEY UPDATE语法，插入时如果遇到唯一约束冲突就直接返回失败，不需要提前查询，也能避免该问题。但要注意这种语法的兼容性，不同数据库的冲突处理语法存在差异。

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