面试八股文---Spring

1.Spring的IOC与AOP的底层实现是什么[重要]?
IOC控制反转，就是将原本在程序中⼿动创建对象的控制权，交由Spring框架来管理。IOC容器实际上就是一个Map(key, value)，Map中存放的是各种对象,它的底层实现是反射和工厂模式
IOC容器：BeanFactory和ApplicationContext 区别？前者是懒加载
AOP是面向切面编程，可以在不惊动源码的情况下进行功能增强。底层实现是动态代理，默认是JDK动态代理，若目标对象没有实现任何接口，会使用CGLIB动态代理
JDK动态代理：被代理类要实现一个接口，通过和被代理类实现相同的接口来进行增强，代理类和被代理类类似于 兄弟关系
具体写法Proxy.newProxyInstance
CGLIB动态代理：被代理类没有要求，通过继承被代理类来实现代理增强，代理类和被代理类 类似于 父子关系
具体写法Enhancer
AOP具体应用：日志处理–自定义注解、环绕通知获取方法名，方法执行时间，方法返回值
2.Spring的bean的作用域有哪些?
singleton 单例，prototype 非单例(原型)，request 为每次请求创建一个对象
session 同一次会话创建一个对象，globalsession 全局应用共享

3.事务的四大(ACID)特性，隔离级别及不同隔离级别的问题是什么[重要]?
原子性Atomicity 事务不能再被拆分为更小的执行单元
一致性Consistency 事务执行前后数据总体保持一致
隔离性Isolation 多个事务之间互相隔离
持久性Durability 事务在提交或者回滚之后对数据库的影响是持久的
事务的隔离级别
读未提交 可能会有脏读、幻读、不可重复读问题
读已提交 可能会有幻读、不可重复读问题
可重复读 可能会有幻读问题，这个级别是mysql数据库默认的隔离级别
串行化 可以避免脏读、幻读、不可重复读的问题，但是会对整张表加锁，性能下降。
**相关原理 spring事务–》JDBC事务–》数据库事务–》数据库锁（排他锁、共享锁、临键锁）

4.spring事务的实现方式以及原理？
Spring本身没有事务功能，spring事务的实现依赖于底层数据库的事务支持。
Spring框架提供了两种事务实现方式：编程式事务、声明式事务（@Transactional）
编程式事务：在代码中进行事务控制。优点：精度高。缺点：代码耦合度高。一般我们很少使用编程式事务，更多的是使用@Transactional注解实现。
当使用了@Transactional注解后事务的自动提交功能就会关闭，由spring帮助实现事务的控制。
Spring的事务管理是通过AOP代理实现的，对被代理对象的每个方法进行拦截，在方法执行前启动事务，
在方法执行完成后根据是否有异常及异常的类型进行提交或回滚。

5.spring事务什么情况下会失效[重要]？
①数据库不支持事务，比如mysql，它的InnoDB引擎是支持事务的，但是MyISAM引擎就不支持事务
②抛出的异常类型不是RuntimeException，或者try catch手动处理了异常，前面一种情况可以使用rollbackFor 属性 指定对某种异常进行回滚
③Spring声明式事务（@Transactional）是基于AOP的，如果类修饰符非public导致类不能被继承，也会导致事务失效
④在类中直接调用自己的方法，同样也不会产生代理，从而不能使事务生效。
⑤事务的传播行为不支持
⑥分布式环境下，操作不同的数据库导致事务整体失效

扩展背诵
6.Spring事务的传播行为（propagation）有哪些？*
①REQUIRE（默认） 根据需求，如果事务管理员开启了事务，事务协调员会加入该事务中运行，如果没有开启，事务协调员自身新建事务运行。
②REQUIRE_NEW 需要新事务，无论事务管理员是否开启事务，事务协调员都新建事务运行。
③SUPPORTS 支持事务，如果事务管理员开启了事务，事务协调员则加入该事务运行，如果没有开启事务则以非事务运行
④NOT_SUPPORTED 不支持事务，无论事务管理员是否开启事务，事务协调员都以非事务运行
⑤MANDATORY 强制，如果事务管理员开启了事务，事务协调员则加入该事务运行，如果没有开启事务则 报错
⑥NEVER 从不，如果事务管理员开启了事务，事务协调员则报错，如果没有开启事务，则以非事务运行
⑦NESTED 嵌套，NESTED会开始一个 “嵌套的” 事务， 它是已经存在事务的一个真正的子事务。 嵌套事务开始执行时， 它将取得一个 savepoint。 如果这个嵌套事务失败， 我们将回滚到此 savepoint。 嵌套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。

7.谈一谈分布式事务的解决方案？*
2PC、3PC、TCC、MQ分布式事务
具体实现：我们项目中主要用Seata去实现分布式事务的管理。
-----Seata的组成部分，TM,RM,TC
-----Seata的XA、AT、TCC事务模式的工作流程
XA：
是seata对2PC模式的实现，保障事务的强一致性，缺点是可用性降低
第一阶段：1、在TC注册分支事务 2、Seata代理SQL的执行，但不提交 3、向TC报告状态
第二阶段：TC检查各分支事务的状态，如果都成功则全部提交，如果有失败则全部回滚
实现方式：application.xml配置 seata.data-source-proxy-mode: XA、给发起全局事务的入口方法添加@GlobalTransactional注解
AT:
保障事务的高可用性，缺点是软状态，只保证事务最终一致。是Seata的默认模式
第一阶段：1、在TC注册分支事务 2、记录提交前后的undo_log 3、Seata代理SQL的执行，直接提交 4、向TC报告状态
第二阶段：提交操作-直接删除undo_log即可，回滚操作-根据undo-log恢复数据到更新前
写隔离：由于第一阶段事务直接提交，在其他分支事务访问到的可能是临时的数据，如果最终事务回滚了，可能造成赃写问题。因此需要让分支事务在提交前先获取全局锁。
读隔离：如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE (排它锁)语句的代理。让读操作也去申请全局锁
实现方式：导入数据库表，记录全局锁、application.xml配置 seata.data-source-proxy-mode: AT
TCC: TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法
Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。
TCC最大的特点是，不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
SAGA:长事务