【Spring面试】八、事务相关
文章目录
- Q1、事务的四大特性是什么？
- Q2、Spring支持的事务管理类型有哪些？Spring事务实现方式有哪些？
- Q3、说一下Spring的事务传播行为
- Q4、说一下Spring的事务隔离
- Q5、Spring事务的实现原理
- Q6、Spring事务传播行为的实现原理是什么？
- Q7、Spring多线程事务，能否保证事务的一致性？
- Q8、Spring事务失效的原因？
Q1、事务的四大特性是什么？
答案：
即ACID：
- 原子性，Atomicity，即事务包含的所有操作要么同成功，要么同失败
- 一致性，Cosistency，即事务必须使得数据库从一个一致性状态到两一个一致性状态。如用户A和用户B两者的钱加起来一共5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加来应该还得是5000，这就是事务的一致性
- 隔离性，Isolation，多个事务并发时，之间要相互隔离，不能被其他事务干扰
- 持久性，Durability，事务一旦提交，对数据库中数据的改变就是永久的，即使数据库故障也不会丢失提交事务的操作
Q2、Spring支持的事务管理类型有哪些？Spring事务实现方式有哪些？
答案： 支持的事务管理类型有两种
Spring支持两种类型的事务管理：
- 编程式事务管理：灵活性高，但难维护
@Autowired
TransactionTemplate transactionTemplate ;
- 声明式事务管理：业务代码和事务管理分离，只需用注解和xml配置来管理事务。以下为基于注解
@Transactional：
答案： 实现声明式事务的三种方式
- 基于接口：Spring早期版本时用，更接近底层源码，有基于TransactionInterceptor的声明式事务，基于TransactionProxyFactoryBean的声明式事务
- 基于
和 - 基于@Transactional的全注解方式：在需要实施事务管理的方法或者类上加@Transactional注解，指定事务规则即可实现事务管理
Q3、说一下Spring的事务传播行为
答案：
两个事务方法之间的嵌套调用时，这个事务方法如何进行，即事务的传播特性。
@Transactional
public void trans(){
sub();
log();
query();
}
@Transactional //SUPPORTS
public info query(){
}
@Transactional //REQUIRES_NEW
public void log(){
}
以上面的query方法为例，其用SUPPORTS，即单独执行时不开启事务（就一个查询，当然不用开启），被有事务的外部方法调用时，则融入到这个外部方法的事务中，与他们同成功，同失败。（到大学了，和其余室友住一个屋子，还是你自己外面租一个新房子）
Q4、说一下Spring的事务隔离
答案：
事务隔离用来解决并发事务所产生的一些问题：
- 脏读
- 不可重复读
- 幻影读
通过设置不同的隔离级别，可解决以上问题。
脏读：
事务2只是改了余额，但并未提交，事务1就把这个没提交的值读走了，如果以后事务2最终回滚，就出问题了。即一个事务读取了另一个事务中没有提交的数据，会在本事务中产生数据不一致的问题。
@Transactional(isolation = isolation.READ_COMMITTED)
设置事务隔离策略为读已提交，只读别的并发事务已提交的修改。
不可重复读：
事务1先读后去处理其他事儿，然后期间事务2修改并commit，等事务1再读，则产生数据不一致的问题。
@Transactional(isolation = isolation.REPEATABLE_READ)
设置事务隔离策略为可重复读REPEATABLE_READ，确保事务1可以多次从一个字段中读到相同的值，即事务1执行期间禁止其他事务对这个字段进行更新（行锁）。
幻影读：
不可重复读是针对一行数据，而幻影读则是针对整个表，比如两次读取，表中多出了一行数据：
即一个事务所在的方法中，多次进行整表数据读取，结果不一样，产生数据不一致问题。
@Transactional(isolation = isolation.SERIALIZABLE)
需要设置事务级别为串行化SERIALIZABLE，确保事务1可以多次从一个表中读到相同的行数，事务1执行期间，禁止其他事务对这个表进行增删改，但这样性能十分低下（表锁）
最后，当不设置事务隔离级别时，将默认使用底层所选数据库自身的默认事务隔离级别。
SELECT @@tx_isolation;
Q5、Spring事务的实现原理
以JavaConfig的方式为例，使用是：
//启动事务，这样可以使用@Transactional注解
@EnableTransactionManagement
答案：
没有Spring之前，单靠JDBC来操作是这样的：
try {
//...
//将事务提交机制改为手动提交
conn.setAutoCommit(false);
//业务逻辑
//在这里事务结束，手动提交数据
conn.commit();
}
Spring事务是把上面业务逻辑前后的事务开启与提交用AOP包了一下，即原理是：Spring事务底层是基于数据库事务和AOP机制。
- 为使用了@Transactional注解的Bean创建一个动态代理对象（bean初始化后调用bean的后置处理器来创建动态代理）
- 如果是事务方法（类上面、接口上面、方法上面、接口方法上面），则开启事务：
try{
- 创建数据库连接
- 修改数据库连接的autocommit属性为false，禁止此连接自动提交
- 执行当前方法，方法中会执行数据库操作的业务SQL
-
}catch{
- 若出现异常，且这个异常需要回滚，则回滚事务
}
- 没有发生异常，则提交事务
Q6、Spring事务传播行为的实现原理是什么？
答案：
Spring的事务信息是存于ThreadLocal中的，所以一个线程永远只能有一个事务。对于被调用的事务方法，当：
- 融入：当传播行为是融入外部事务，则拿到ThreadLocal中的Connection，共享一个数据库连接，来共同提交与回滚
- 创建新事务：当传播行为是创建新的事务，则会把嵌套的新事务存入ThreadLocal，再将外部暂存起来，当嵌套事务提交或回滚后，再将暂存的外部事务信息恢复到ThreadLocal来提交或回滚
详细流程：
- 外部：创建数据库连接Connection并存入ThreadLocal，修改数据库连接的autocommit属性为false
- 外部：返回事务状态信息（
TransactionInfo.newTransaction=true) - 外部：往下执行方法，中途发现
内部调用了另一个事务方法 - 内嵌：判断当前ThreadLoacl是否已有Connection，有即是内嵌事务，需要判断事务传播行为，到此分两种情况
情况一，当传播行为是融入：
- 不会创建connection，返回事务状态信息（
TransactionInfo.newTransaction=false)，即不是一个新事务 - 内部被调用的事务方法开始执行相关SQL
- 执行完后，判断TransactionInfo.newTransaction是否为true，此时是融入，这个值为false，不提交
- 内部被调用的事务方法执行完成
- 外部方法继续往下执行
- 执行完后判断TransactionInfo.newTransaction是否为true，外部为true
- 拿到ThreadLocal中的connection进行提交
情况二，当传播行为是创建新的事务：
- 把外层方法事务相关的事务信息（包括connection、隔离级别、是否只读…）暂存到TransactionInfo中，同时会把ThreadLocal中的事务信息置空
- 创建新的connection，返回事务状态信息（
TransactionInfo.newTransaction=true)，即新事务，并放入ThreadLocal当中 - 内部被调用的事务方法往下执行
- 执行完后判断TransactionInfo.newTransaction是否为true⇒是⇒于是提交
- 判断是否暂存了事务 ⇒ 是⇒ 再把上面暂存的外部方法的事务信息放回ThreadLocal中
- 内部被调用的事务方法执行完成
- 外部事务方法接着执行
- 执行完后判断TransactionInfo.newTransaction是否为true，外部为true
- 拿到ThreadLocal中的connection进行提交
Q7、Spring多线程事务，能否保证事务的一致性？
问题分析：两个事务方法A和B，在两个线程中，对应的事务能否同时提交或回滚？
答案：
Spring不支持，因为Spring事务信息存于ThreadLocal中的Connection，一个线程永远只能有一个事务，所以无法实现两个事务的一致性。可以通过编程式事务自己控制或者分布式事务来解决（二阶段提交的方式）。
Q8、Spring事务失效的原因？
Spring事务底层是基于数据库事务和AOP机制，因此，参考AOP失效，可以知道Spring事务失效的原因：
答案：
- 方法的内部调用导致事务传播失效
- 方法是private会失效，解决: 改成public
- 目标类没有配置为Bean也会失效 解决: 配置为Bean，交给Spring管理
- 自己捕获了异常 解决: 不要捕获处理
- 使用cglib动态代理，但是@Transactional声明在接口上面
后面几种本质上是使用不当导致的失效。