一段被Try-Catch包裹的代码，差点让我丢了工作！
作者：互联网
“
一段被 try-catch 包裹后的代码在产线稳定运行了 200 天后忽然发生了异常，而这个异常竟然导致了产线事务回滚。
图片来自 Pexels
这期间究竟发生了什么？日常在项目过程中该如何避免事务异常？就在这个时候，老板拿着《XX 公司关于三十岁员工优化通知》走了过来......
01
产线部分数据丢失了，因为一个蹊跷的事务回滚。而造成事务回滚的，竟然是一段被 try-cath 包裹后的代码，一段已经在产线稳定运行了 200 天的代码，稳定到我们已经把它遗忘了。
谁也没想到的是，它竟然以这样一种方式重新回到了我们的视野，宣告着它的存在！
小九九是一个永远 19 岁的程序员，和所有程序员一样地阳光、帅气（这句话不管你信不信，反正我自己也不信。为了能够开始今天的文章，就这么瞎编吧，总比以“一个没有头发的程序员”开头的好）。
当他告诉我一段 try-catch 的代码造成产线事务回滚后，我温柔、耐心地对他说：“滚一边去，没看我正忙着吗？”，然后他给我甩出了一段代码，用猥琐又真诚的眼睛告诉我，他说的是真的。
02
我们来看一下这段导致了产线事务回滚的代码，类似于下面这样的：
@Transactional
public void main() {
// 假设有多个user的操作，需要事务控制
methodA();
try {
orderService.methodB();
} catch (Exception e) {
// order失败了不能影响该方法,不回滚。
// 异常处理，略
}
userOtherProcess();
}
methodA 方法需要事务控制，methodB 方法不管遇到什么异常都不能影响 A 事务，所以加了 try-catch。
可能有的人和我的第一反应一样，是不是最后的 userOtherProcess 方法执行异常造成了 methodA 的事务回滚？
小九九告诉我真的是因为 methodB，这段代码当初经过严格的测试，而且已经 200 天没人碰过了。
也可能已经有人猜出了问题的原因了，这里先卖个关子，因为这件事情里，最重要的是这个坑是如何一步步产生的。
为了更形象地描述这个事情我画一个图，红色背景表示该方法是有事务控制的，白色背景表示该方法没有事务：
一开始的时候，正如大家所看到的代码，methodA 方法有事务，methodB 无事务且被 try-catch 包裹了，运行得很完美。
过了一段时间后来到了阶段二，因为一些需求变更新增了 methodC，该业务也依赖了 methodB，依然很完美地上线了。
过了一段时间来到了阶段 3，依赖 methodC 相关业务再次发生了变更，需要在 methodB 里增加一些逻辑且需要事务控制。
经过评估确实对 methodA 没有影响，于是经过充分测试后再次完美地上线了，然而隐藏的炸弹就在这个时候埋下了。
小伙伴们这个时候应该已经猜到原因了，是的，你猜的没错。某一天 methodA 调用 methodB 时 methodB 发生了异常，由于是继承性事务，虽然 methodB 发生了异常被 try-catch 了，依然造成了 methodA 事务回滚。
还没有理解的小伙伴，可以看下面这张图：
我们可以把事务控制机制理解为上图这样一个红色的长长的房间，这个房间是有人看守的，他负责事务的开始、提交，还有一项重要的任务就是监控异常。
一旦发现 RuntimeException 异常直接回滚整个事务，我们给他一个 title，称之为“监事”吧。
再来看阶段三和一开始的代码，方法的开头有一个 @Transactional 注解，于是他打开了这个红色房间的门，把 methodA 放了进去。
接着 methodB 过来了，也开启了事务--继承性事务，于是监事把 methodB 也安排到了这个房间。
methodB 虽然发生了异常且被 try-catch 包裹，但逃不过监事的火眼金睛，于是他按下了事务回滚的按钮。
这样理解了之后，我们再来简单看一下源码：
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
at org.springframework.transaction.support.AbstractPlatformTransactionManager.proce***ollback(AbstractPlatformTransactionManager.java:873)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:710)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:534)
根据异常提示，可以看到错误发生在 AbstractPlatformTransactionManager 的 873 行 proce***ollback 方法。
通过 Find Usages 找到调用方 commit 方法，显然这是一段事务提交的逻辑。
@Override
public final void commit(TransactionStatus status) throws TransactionException {
// 为便于阅读，删除部分代码
......
if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
// 为便于阅读，删除部分代码
proce***ollback(defStatus, true);
return;
}
processCommit(defStatus);
}
defStatus.isGlobalRollbackOnly()：判断是否是读取 DefaultTransactionStatus 中 transaction 对象的 ConnectionHolder 的 rollbackOnly 标志位。
继续往上追溯，来到 TransactionAspectSupport.invokeWithinTransaction 方法：
@Nullable
protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
final InvocationCallback invocation) throws Throwable {
// 为便于阅读，删除部分代码
......
// 如果是声明式事务
if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
// Standard transaction demarcation with getTransaction and commit/rollback calls.
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal;
try {
// This is an around advice: Invoke the next interceptor in the chain.
// This will normally result in a target object being invoked.
// 执行事务方法
retVal = invocation.proceedWithInvocation();
}
catch (Throwable ex) {
// 捕获异常，并将会把事务设置为Rollback回滚状态。
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
cleanupTransactionInfo(txInfo);
}
// 提交事务
commitTransactionAfterReturning(txInfo);
return retVal;
}
else {
// 声明式事务，略
}
}
整个执行过程参见注释说明，其它源码就不罗列了。Spring 捕获异常后，正如我们所猜测的，事务将会被设置全局 rollback。
而最外层的事务方法执行 commit 操作，这时由于事务状态为 rollback，Spring 认为不应该 commit 提交事务，而应该回滚事务，所以抛出 rollback-only 异常。
03
还有一个比较典型的事务问题就是：在同一个类中，mehtodA 没有事务，mehtodB 开启了（声明式）事务。
此时 mehtodA 调用 mehtodB 时事务是不生效的：
如上面这张图所示，我们还是把 AOP 想像成一个长方形的房间，由于 mehtodA 没有事务，这个房间已经被标志为没有事务无人值守了，mehtodB 虽然标记了事务，但很显然是不生效的。
接下来我们重新回顾一下事务的几种配置：
REQUIRED：支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
REQUIRES_NEW：新建事务，如果当前存在事务，把当前事务挂起。
SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。
MANDATORY：支持当前事务，如果当前没有事务，就抛出异常。
NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
NESTED：支持当前事务，如果当前事务存在，则执行一个嵌套事务，如果当前没有事务，就新建一个事务。
这方面的文章很多，这里就不做描述了。
04
事务问题本身是比较难通过测试发现的，我们再来聊一聊项目过程中如何防止事务问题的发生。
比如笔者之前曾负责过支付及资金处理相关系统，产品的单笔交易额比较大，每笔至少 1 万+，正常 10 万+，很多时候一笔支付就是 300 万，所以容不得出现一笔资金差错。好在我们资金交易从 0 做到了 3000 亿，依然资金 0 差错。
针对可能的事务问题，我们采取的措施有：
通过开发规范、产线坑集等文档、培训等让开发人员对事务有足够的了解、敏感度。
系统设计时，对于关键的业务场景需要写明是否启用了事务，哪些方法包裹在一个事务中，并进行评审。
代码 Review 环节有很多专项 Review，比如资金 Review、多线程 Review 等等，也有一项专门的事务 Review：需不需要加事务？事务配置是否正确？异常是否处理等。
开发人员构造事务异常场景进行自测、交叉验证。
测试团队参与系统设计评审，并进行事务相关测试。比如通过防火墙阻断请求、手动锁表等方式来模拟可能的事务异常。
笔者在之前一家公司还有一种做法就是通过开发规范约束：所有事务的方法全部以 tx 开头。
比如 methodB 方法需要开启事务，则新增一个 txMethodB 方法，在该方法中调用 methodB。通过这种方式完全可以避免上面问题的发生，但很显然这种方式相当地“丑陋”。
05
正和小九九聊着事务问题，老板手里拿着几张 A4 纸走了过来。
作为公司唯一的 30 岁程序员，我提高了声音对小九九说：你有没有发现 @Transactional 中还有一个配置项 readOnly，如果需要使用这个参数，必须启动一个事务。
但如果是读取数据，根本就不需要事务啊？为什么会有这么一个自相矛盾的配置项呢？小九九一脸茫然地摇了摇头。
老板冲我点了点头，转身回到了办公室，坐下思考了一会，然后把手里的 A4 纸《XX 公司关于三十岁员工优化通知》放到了抽屉一叠资料的最下面，接着又抽出来放到了资料的中间。
看来我的程序生涯，又可以持续一段时间了！
标签：try,事务,代码,回滚,Try,methodB,Catch,包裹,异常 来源： https://blog.51cto.com/14410880/2545888