系统性能优化之编程式事务
一、示例代码
用户下单后要进行发货，伪代码如下：
/**
* 订单发货
* @param orderId
*/
@Transactional(rollbackFor = Exception.class)
public void sendOrder(String orderId){
// 1、查询订单
// 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时2秒钟
// 3、更新订单状态
}
正常情况下，我们都会常规性地在接口方法上加上事务注解@Transactional。但有一天，高峰时期系统突然无法访问，出现假死。当然系统不是真的宕机，而是所有和数据库有关的连接都被阻塞，连接池已经无法获取连接了。
二、原因分析
通常情况下，大部人的解决办法是调整数据库连接池大小，认为是高峰时期系统设置的连接池数量大小，不足以支撑早高峰的连接数量导致的，如将数据库连接池的数量调整到了200甚至更大。
即使将配置调整成了200，服务重启也恢复了正常，但这是指标不治本的一种处理方式，只有找到了真正的原因才能从根本上解决这个问题。
通过仔细分析后我们可以发现，在sendOrder加上@Transactional 事务注解后，请求刚进入sendOrder方法时，就会从数据库连接获取一个连接。可是此时，程序并没有和数据库相关的操作，如果此时代码在步骤2远程调用接口时出现io或者网络阻塞，就会导致事务无法提交，连接也就会一直被该请求占用，而再大的连接池也会被耗费殆尽，从而造成系统崩溃。
三、错误的解决办法
3.1 将需要加事务的代码块抽取成子方法并加事务注解
首先分析有没有需要使用事务的必要。在步骤3中，数据操作，看代码后发现只有对一张表的操作，同时和其它操作没有相关性。而且本身属于最后一个步骤。所以在此代码中完全没有必要使用，删除注解即可。
当然如果步骤3操作数据库是多表操作，具有强相关性，数据一致，我们可以这样做，将步骤3无关的步骤分开，变成两个方法，那么在步骤2处发生阻塞也不会影响到数据库连接。
/**
* 订单发货
* @param orderId
*/
public void sendOrder(String orderId){
// 1、查询订单
// 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时5秒钟
this.updateOrder();
}
@Transactional(rollbackFor = Exception.class)
public void updateOrder(){
// 3、更新订单状态
}
这种方式看上去似乎没什么毛病，但这种方式updateOrder方法上的@Transactional事务注解是无效的，这就是Spring事务注解失效的问题。
事务注解为什么会失效呢，我们需要研究下@Transactional注解的原理：
Spring之所以可以对开启@Transactional的方法进行事务管理，是因为Spring为当前类生成了一个代理类，然后在执行相关方法时，会判断这个方法有没有@Transactional注解，如果有的话，则会开启一个事务。
sendOrder()方法是被代理类执行的，但该方法上没有写事务注解，所以不会执行事务。另外updateOrder()方法是被当前类this调用的，而不是Spring的动态代理类，所以updateOrder()方法上即使写了事务注解，但也不会执行事务，从而导致@Transactional失败。
可参考：
Spring事务注解@Transactional失效和切面失效问题
四、正确的解决办法
4.1 编程式事务
通过代码分析，只有步骤3才需要进行事务控制（如果步骤3有多表操作），步骤1和步骤2都不需要事务控制，因此我们可以通过编程式事务来精确为步骤3加上事务。
private TransactionTemplate template;
/**
* 订单发货
* @param orderId
*/
public void sendOrder(String orderId){
// 1、查询订单
// 2、用RestTemplate调用远程物流接口发货 ---- 需要耗时5秒钟
// 编程式事务，手动控制哪些代码块要加事务控制
template.execute(new TransactionCallback<Object>() {
@Override
public Object doInTransaction(TransactionStatus transactionStatus) {
// 3、更新订单状态
return null;
}
});
}
推荐阅读：一次线上故障：数据库连接池泄露后的思考
