异步事务调用后查询持久化对象为null的问题及方案探讨

这是个典型的异步事务间数据可见性问题——因为两个@Asynchronous方法各自属于独立事务，默认的READ COMMITTED隔离级别下，第二个事务只能读取到已提交的数据，而第一个事务还没完成提交，所以查询返回null。加休眠只是靠运气“赌”第一个事务提交完成，完全不可靠，下面是几个更合理的优化思路：

1. 确保第一个事务提交后再触发第二个异步任务 #

实现思路 #

把runExport里的事务操作和异步调用拆分：先在一个同步的事务方法里完成persist并确保事务提交，再启动第二个异步任务。

代码示例 #

// 抽离同步事务方法
@Transactional
public void persistTestObject(Long id) {
    /* 耗时操作 */
    em.persist(objectTest);
}

@Asynchronous
@TransactionTimeout(value = 12, unit = TimeUnit.HOURS)
public void runExport(Long id) {
    // 先执行同步事务，确保数据提交到数据库
    persistTestObject(id);
    // 再触发第二个异步任务
    manager.runAnotherTransaction(id);
}

优缺点 #

• 优点：从根源解决可见性问题，完全符合事务隔离性要求，没有脏读风险；逻辑清晰，容易维护。
• 缺点：需要调整现有方法结构；如果第一个事务本身耗时很长，第二个任务的启动会被延迟，整体流程耗时会增加。

2. 利用Spring事务同步机制触发后续任务 #

实现思路 #

在第一个事务内部注册一个事务同步回调，只有当事务成功提交后，才执行第二个异步任务的调用。

代码示例 #

@Asynchronous
@TransactionTimeout(value = 12, unit = TimeUnit.HOURS)
public void runExport(Long id) {
    /* 耗时操作 */
    em.persist(objectTest);
    
    // 注册事务提交后的回调
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
        @Override
        public void afterCommit() {
            // 事务提交成功后，再触发第二个任务
            manager.runAnotherTransaction(id);
        }
    });
}

优缺点 #

• 优点：精准控制第二个任务的启动时机，既保证数据可见性，又不需要拆分方法；异步特性保留，不会阻塞主线程；如果第一个事务回滚，第二个任务会自动取消，符合业务逻辑。
• 缺点：代码有一定复杂度，需要理解Spring事务同步的原理；回调内的异常排查相对麻烦，需要额外的日志或监控。

3. 调整事务隔离级别（不推荐，仅特殊场景使用） #

实现思路 #

把第二个事务的隔离级别改为READ UNCOMMITTED，允许读取其他事务未提交的数据。

代码示例 #

@Asynchronous
@TransactionTimeout(value = 1, unit = TimeUnit.HOURS)
@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void runCopy(Long id) {
    if(manager.isPreviousValueCommited(id)){
        //执行操作
    }
    /* 耗时操作 */
}

优缺点 #

• 优点：不需要修改调用流程，只需要调整注解配置，改动最小。
• 缺点：严重破坏事务隔离性，会出现脏读（如果第一个事务回滚，第二个事务读到了根本不存在的数据），数据一致性风险极高；不是所有数据库都支持该隔离级别，兼容性差。

4. 用消息队列解耦两个事务 #

实现思路 #

第一个事务提交后，发送一条消息到消息队列（如RabbitMQ、Kafka），消费端监听消息后再执行第二个事务的逻辑。

代码示例（伪代码） #

@Asynchronous
@TransactionTimeout(value = 12, unit = TimeUnit.HOURS)
public void runExport(Long id) {
    /* 耗时操作 */
    em.persist(objectTest);
    // 事务提交后发送消息
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
        @Override
        public void afterCommit() {
            messageProducer.send("copy-task-topic", id);
        }
    });
}

// 消费端
@RabbitListener(queues = "copy-task-queue")
public void handleCopyTask(Long id) {
    superBean.runCopy(id);
}

优缺点 #

• 优点：彻底解耦两个操作，提高系统扩展性和容错性；消息队列自带重试机制，失败后可自动重试；天然支持异步，不依赖Spring的@Asynchronous。
• 缺点：引入中间件，增加系统复杂度和运维成本；需要处理消息幂等性（防止重复消费）；消息传递有一定延迟，实时性不如直接调用。

对比你提到的「直接传递对象」方案 #

优缺点 #

• 优点：简单直接，避免了数据库查询，性能更高；完全绕过事务可见性问题。
• 缺点：如果对象体积大，会占用更多内存/网络资源（跨服务场景更明显）；对象在传递过程中可能被修改，导致数据不一致；如果第二个任务需要基于数据库最新状态操作，传对象无法反映后续变更；序列化/反序列化可能带来额外开销和兼容性问题。

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