共计 5404 个字符，预计需要花费 14 分钟才能阅读完成。
Java 后端面试的时候，面试官常常会问到 @Transactional 的原理，以及容易踩的坑，之前一面百度，就遇到过，明天就带大家把这几块常识吃透。
这篇文章，会先讲述 @Transactional 的 4 种不失效的 Case，而后再通过源码解读，剖析 @Transactional 的执行原理，以及局部 Case 不失效的真正起因。
我的项目筹备
上面是 DB 数据和 DB 操作接口：
uidunameusex1 张三女 2 陈恒男 3 楼仔男
// 提供的接口
public interface UserDao {
// select * from user_test where uid = “#{uid}”
public MyUser selectUserById(Integer uid);
// update user_test set uname =#{uname},usex = #{usex} where uid = #{uid}
public int updateUser(MyUser user);
}
复制代码
根底测试代码，testSuccess() 是事务失效的状况：
@Service
public class UserController {
@Autowired
private UserDao userDao;
public void update(Integer id) {
MyUser user = new MyUser();
user.setUid(id);
user.setUname(“ 张三 -testing”);
user.setUsex(“ 女 ”);
userDao.updateUser(user);
}
public MyUser query(Integer id) {
MyUser user = userDao.selectUserById(id);
return user;
}
// 失常状况
@Transactional(rollbackFor = Exception.class)
public void testSuccess() throws Exception {
Integer id = 1;
MyUser user = query(id);
System.out.println(“ 原记录:” + user);
update(id);
throw new Exception(“ 事务失效 ”);
}
}
复制代码
事务不失效的几种 Case
次要解说 4 种事务不失效的 Case：
类外部拜访：A 类的 a1 办法没有标注 @Transactional，a2 办法标注 @Transactional，在 a1 外面调用 a2；
公有办法：将 @Transactional 注解标注在非 public 办法上；
异样不匹配：@Transactional 未设置 rollbackFor 属性，办法返回 Exception 等异样；
多线程：主线程和子线程的调用，线程抛出异样。
Case 1: 类外部拜访
咱们在类 UserController 中新增一个办法 testInteralCall()：
public void testInteralCall() throws Exception {
testSuccess();
throw new Exception(“ 事务不失效：类外部拜访 ”);
}
复制代码
这里 testInteralCall() 没有标注 @Transactional，咱们再看一下测试用例：
public static void main(String[] args) throws Exception {
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(“applicationContext.xml”);
UserController uc = (UserController) applicationContext.getBean(“userController”);
try {
uc.testSuccess();
} finally {
MyUser user = uc.query(1);
System.out.println(“ 批改后的记录:” + user);
}
}
// 输入：
// 原记录:MyUser(uid=1, uname= 张三, usex= 女)
// 批改后的记录:MyUser(uid=1, uname= 张三 -testing, usex= 女)
复制代码
从下面的输入能够看到，事务并没有回滚，这个是什么起因呢？
因为 @Transactional 的工作机制是基于 AOP 实现，AOP 是应用动静代理实现的，如果通过代理间接调用 testSuccess()，通过 AOP 会前后进行加强，加强的逻辑其实就是在 testSuccess() 的前后别离加上开启、提交事务的逻辑，前面的源码会进行分析。
当初是通过 testInteralCall() 去调用 testSuccess()，testSuccess() 前后不会进行任何加强操作，也就是类外部调用，不会通过代理形式拜访。
如果还是不太分明，举荐再看看这篇文章，外面有残缺示例，十分完满诠释“类外部拜访”不能前后加强的起因：blog.csdn.net/Ahuuua/arti…
Case 2: 公有办法
在公有办法上，增加 @Transactional 注解也不会失效：
@Transactional(rollbackFor = Exception.class)
private void testPirvateMethod() throws Exception {
Integer id = 1;
MyUser user = query(id);
System.out.println(“ 原记录:” + user);
update(id);
throw new Exception(“ 测试事务失效 ”);
}
复制代码
间接应用时，上面这种场景不太容易呈现，因为 IDEA 会有揭示，文案为: Methods annotated with ‘@Transactional’ must be overridable，至于深层次的原理，源码局部会给你解读。
Case 3: 异样不匹配
这里的 @Transactional 没有设置 rollbackFor = Exception.class 属性：
@Transactional
public void testExceptionNotMatch() throws Exception {
Integer id = 1;
MyUser user = query(id);
System.out.println(“ 原记录:” + user);
update(id);
throw new Exception(“ 事务不失效：异样不匹配 ”);
}
复制代码
测试方法：同 Case1
// 输入：
// 原记录:User[uid=1,uname= 张三,usex= 女]
// 批改后的记录:User[uid=1,uname= 张三 -test,usex= 女]
复制代码
@Transactional 注解默认解决运行时异样，即只有抛出运行时异样时，才会触发事务回滚，否则并不会回滚，至于深层次的原理，源码局部会给你解读。
Case 4: 多线程
上面给出两个不同的姿态，一个是子线程抛异样，主线程 ok；一个是子线程 ok，主线程抛异样。
父线程抛出异样
父线程抛出异样，子线程不抛出异样：
public void testSuccess() throws Exception {
Integer id = 1;
MyUser user = query(id);
System.out.println(“ 原记录:” + user);
update(id);
}
@Transactional(rollbackFor = Exception.class)
public void testMultThread() throws Exception {
new Thread(new Runnable() {
@SneakyThrows
@Override
public void run() {
testSuccess();
}
}).start();
throw new Exception(“ 测试事务不失效 ”);
}
复制代码
父线程抛出线程，事务回滚，因为子线程是独立存在，和父线程不在同一个事务中，所以子线程的批改并不会被回滚，
子线程抛出异样
父线程不抛出异样，子线程抛出异样：
public void testSuccess() throws Exception {
Integer id = 1;
MyUser user = query(id);
System.out.println(“ 原记录:” + user);
update(id);
throw new Exception(“ 测试事务不失效 ”);
}
@Transactional(rollbackFor = Exception.class)
public void testMultThread() throws Exception {
new Thread(new Runnable() {
@SneakyThrows
@Override
public void run() {
testSuccess();
}
}).start();
}
复制代码
因为子线程的异样不会被内部的线程捕捉，所以父线程不抛异样，事务回滚没有失效。
源码解读
上面咱们从源码的角度，对 @Transactional 的执行机制和事务不失效的起因进行解读。
@Transactional 执行机制
咱们只看最外围的逻辑，代码中的 interceptorOrInterceptionAdvice 就是 TransactionInterceptor 的实例，入参是 this 对象。
红色方框有一段正文，大抵翻译为“它是一个拦截器，所以咱们只需调用即可：在结构此对象之前，将动态地计算切入点。”
this 是 ReflectiveMethodInvocation 对象，成员对象蕴含 UserController 类、testSuccess() 办法、入参和代理对象等。
进入 invoke() 办法后：
后方高能！！！这里就是事务的外围逻辑，包含判断事务是否开启、指标办法执行、事务回滚、事务提交。
private 导致事务不失效起因
在下面这幅图中，第一个红框区域调用了办法 getTransactionAttribute()，次要是为了获取 txAttr 变量，它是用于读取 @Transactional 的配置，如果这个 txAttr = null，前面就不会走事务逻辑，咱们看一下这个变量的含意：
咱们间接进入 getTransactionAttribute()，重点关注获取事务配置的办法。
后方高能！！！这里就是 private 导致事务不失效的起因所在，allowPublicMethodsOnly() 始终返回 false，所以重点只关注 isPublic() 办法。
上面通过位与计算，判断是否为 Public，对应的几类修饰符如下：
PUBLIC: 1
PRIVATE: 2
PROTECTED: 4
看到这里，是不是恍然大悟了，有没有觉得很有意思呢~~
异样不匹配起因
咱们持续回到事务的外围逻辑，因为主办法抛出 Exception() 异样，进入事务回滚的逻辑：
进入 rollbackOn() 办法，判断该异样是否能进行回滚，这个须要判断主办法抛出的 Exception() 异样，是否在 @Transactional 的配置中：
咱们进入 getDepth() 看一下异样规定匹配逻辑，因为咱们对 @Transactional 配置了 rollbackFor = Exception.class，所以能匹配胜利：
示例中的 winner 不为 null，所以会跳过上面的环节。然而当 winner = null 时，也就是没有设置 rollbackFor 属性时，会走默认的异样捕捉形式。
后方高能！！！这里就是异样不匹配起因的起因所在，咱们看一下默认的异样捕捉形式：
是不是恍然大悟，当没有设置 rollbackFor 属性时，默认只对 RuntimeException 和 Error 的异样执行回滚。作者：楼仔链接：https://juejin.cn/post/713226… 起源：稀土掘金著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。