从@Transactional到TransactionTemplate：长事务优化实战指南

长事务的问题

1. 连接池耗尽

• 现象：事务执行时间过长（如处理大批量数据），导致数据库连接长时间被占用，其他请求阻塞。
• 根因：@Transactional默认在整个方法执行期间持有连接。

2. 锁竞争与死锁

• 现象：事务中涉及多行数据更新，长时间持有锁，其他事务被阻塞。
• 根因：事务范围过大，锁粒度粗。

3. 事务不可控

• 现象：嵌套调用外部服务（如RPC）、异步任务时，事务边界混乱。
• 根因：@Transactional的传播机制难以应对复杂场景。

✅优化方案：TransactionTemplate手动事务管理

核心优势

• 精准控制事务边界：手动提交/回滚，避免无意义的长时间事务。
• 灵活拆分事务：将长事务拆分为多个短事务，减少锁占用时间
• 资源释放及时：每次操作后立即释放连接，提升连接池利用率。

实战场景与代码改造

1️⃣批量数据导入

问题分析

使用@Transactional一次性提交10万条数据：

@Transactional
public void importBatchData(List<Data> dataList) {
    for (Data data : dataList) {
        dataRepository.save(data); // 单条插入，性能差且事务过长
    }
}

• 缺陷：事务持续到循环结束，锁表时间长，连接不释放。

优化方案

手动分批次提交，每1000条提交一次：

private TransactionTemplate transactionTemplate;

public void importBatchData(List<Data> dataList) {
    int batchSize = 1000;
    for (int i = 0; i < dataList.size(); i += batchSize) {
        List<Data> batch = dataList.subList(i, Math.min(i + batchSize, dataList.size()));
        transactionTemplate.execute(status -> {
            batch.forEach(dataRepository::save); // 使用批量插入
            return null;
        });
    }
}

优势：

• 每批次独立事务，及时释放连接。
• 结合批量插入（如JPA的saveAll()），减少IO次数。

2️⃣外部服务调用嵌套

问题分析

在事务中调用外部RPC服务：

@Transactional
public void processOrder(Order order) {
    orderRepository.save(order);
    rpcService.callExternalSystem(order); // RPC调用耗时不确定
    updateInventory(order); // 后续数据库操作
}

• 缺陷：RPC调用时间不可控，事务持续到RPC返回，容易导致连接池耗尽。

优化方案

拆分事务，RPC调用前提交订单数据：

public void processOrder(Order order) {
    // 第一阶段：快速提交订单
    transactionTemplate.execute(status -> {
        orderRepository.save(order);
        return null;
    });

    // 第二阶段：调用外部服务（非事务内）
    rpcService.callExternalSystem(order); 

    // 第三阶段：更新库存（新事务）
    transactionTemplate.execute(status -> {
        updateInventory(order);
        return null;
    });
}

优势：

• RPC调用不在事务内，避免长时间占用连接。
• 各阶段事务独立，失败后局部回滚。

3️⃣异步任务触发

问题分析

在事务提交后触发异步操作：

@Transactional
public void handleTrade(Trade trade) {
    tradeRepository.save(trade);
    asyncService.sendNotification(trade); // 异步方法可能在事务未提交时执行
}

• 缺陷：异步任务可能在事务未提交时读取中间状态数据。

优化方案

手动提交事务后触发异步任务：

public void handleTrade(Trade trade) {
    transactionTemplate.execute(status -> {
        tradeRepository.save(trade);
        return null;
    });

    // 确保事务已提交，再触发异步操作
    asyncService.sendNotification(trade); 
}

优势：

• 异步任务读取的是已提交的数据，避免脏读。
• 事务粒度更小，连接释放更快

4️⃣分阶段补偿事务

问题分析

长事务包含多步骤操作，某一步失败需回滚全部：

@Transactional
public void multiStageOperation() {
    step1(); // 操作1
    step2(); // 操作2（可能失败）
    step3(); // 操作3
}

• 缺陷：所有操作在一个事务中，失败后全部回滚，无法实现部分补偿。

优化方案

手动分阶段提交，结合补偿机制：

public void multiStageOperation() {
    try {
        transactionTemplate.execute(status -> {
            step1(); // 阶段1
            return null;
        });

        transactionTemplate.execute(status -> {
            step2(); // 阶段2
            return null;
        });

        transactionTemplate.execute(status -> {
            step3(); // 阶段3
            return null;
        });
    } catch (Exception e) {
        compensate(); // 自定义补偿逻辑（如回滚阶段1）
        throw e;
    }
}

优势：

• 各阶段独立提交，失败后仅需补偿已提交的部分。
• 适合最终一致性场景（如投行交易订单）。

避坑指南

1. 务必处理异常！

手动事务需显式处理回滚：

transactionTemplate.execute(status -> {
    try {
        // 业务逻辑
        return result;
    } catch (Exception e) {
        status.setRollbackOnly(); // 标记回滚
        throw e;
    }
});

2. 避免事务嵌套

若需嵌套事务，明确指定传播行为：

TransactionTemplate nestedTemplate = new TransactionTemplate(transactionManager);
nestedTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);

transactionTemplate.execute(status -> {
    // 外层事务
    nestedTemplate.execute(nestedStatus -> { 
        // 内层独立事务
        return null;
    });
    return null;
});

3. 监控事务时长

记录事务执行时间，避免隐性长事务：

transactionTemplate.execute(status -> {
    long start = System.currentTimeMillis();
    // 业务逻辑
    log.info("Transaction cost: {}ms", System.currentTimeMillis() - start);
    return null;
});

---

小总结

在金融级系统中，长事务是性能杀手。通过TransactionTemplate手动管理事务：

1. 拆分长事务为多个短事务，降低锁竞争。
2. 精准控制边界，避免无意义连接占用。
3. 结合补偿机制，提升系统容错性。

适用场景：

• 高频批量操作（如交易数据导入）。
• 涉及外部服务调用的业务流程。
• 需要最终一致性的分布式事务。