Spring学习笔记

spring 是一个开源的轻量级 JavaBean 容器框架。使用 JavaBean 代替 EJB ，并提供了丰富的企业应用功能，降低应用开发的复杂性。

• 轻量：非入侵性的、所依赖的东西少、资源占用少、部署简单，不同功能选择不同的 jar 组合
• 容器：工厂模式实现对 JavaBean 进行管理，通过控制反转（IOC）将应用程序的配置和依赖性与应用代码分开
• 松耦合：通过 xml 配置或注解即可完成 bean 的依赖注入
• AOP：通过 xml 配置 或注解即可加入面向切面编程的能力，完成切面功能，如：日志，事务…的统一处理
• 方便集成：通过配置和简单的对象注入即可集成其他框架，如 Mybatis、Hibernate、Shiro…
• 丰富的功能：JDBC 层抽象、事务管理、MVC、Java Mail、任务调度、JMX、JMS、JNDI、EJB、动态语言、远程访问、Web
  Service…

springMvc 运行原理

1、 用户发送请求至前端控制器DispatcherServlet。
2、 DispatcherServlet收到请求调用HandlerMapping 处理器映射器。
3、 处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。
4、 DispatcherServlet调用HandlerAdapter处理器适配器。
5、 HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。
6、 Controller执行完成返回ModelAndView。
7、 HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。
8、 DispatcherServlet将ModelAndView传给ViewReslover视图解析器。
9、 ViewReslover解析后返回具体View。
10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。
11、 DispatcherServlet响应用户。

简述springIOC或原理

bean 的创建和维护交给spring ioc 来管理，底层用的是反射机制，项目在启动的时候spring 扫描 bean 所在的包，采用反射机制class.forname().newInstence();实例化对象
存储到内部的concurrenthashmap 中。获取对象从concurrenthashmap 获取，依赖注入有三种方式 接口注入、构造器注入、属性注入

简述springAop或原理

spring aop 通过切点指定在哪些类哪些方法进行织入横切逻辑，通过增强描述横切逻辑的具体实现，通过切面把切点和增强链接到一起
spring aop 默认用的是jdk 动态代理，如果代理类没有实现接口，则用cglib,如果代理类实现接口则用的事jdk动态代理
cglib 采用asm 技术操作字节码 使用cglib 需要注意的是代理的方法不能加上final 修饰，jdk动态代理 需要把java 编译成 class 文件然后再操作字节码
aop 应用场景 spring 事物的管理
项目中的应用，比如日志表。用来显示流程图的流转
在spring xml 中 添加 aop 的标签

<!-- 定义aspectj -->
<aop:aspectj-autoproxy proxy-target-class="true" />

定义一个类，这个类必须定义到spring 能扫描的包下面
在类上加上注解
@Aspect
定义一个方法 加上切点的注解 @Pointcut("execution(* com.techstar.service.OrderService.update*(..))")
定一个方法 加上增强的注解

@AfterReturning(value="updateServiceCall()", argNames="rtv", returning="rtv") 

在方法中进行具体的代码实现

Spring常用注解

https://www.jianshu.com/p/71e8971d2bc5?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

springmvc 常用的注解

1. @RequestMapping：用于处理请求地址映射，可以作用于类和方法上。
   value：定义request请求的映射地址
   method：定义地request址请求的方式，包括【GET, POST, HEAD, OPTIONS, PUT, PATCH, DELETE, TRACE.】默认接受get请求，如果请求方式和定义的方式不一样则请求无法成功。
   params：定义request请求中必须包含的参数值。
   headers：定义request请求中必须包含某些指定的请求头，如：RequestMapping(value = “/something”, headers = “content-type=text/*”)说明请求中必须要包含"text/html",
   "text/plain"这中类型的Content-type头，才是一个匹配的请求。
   consumes：定义请求提交内容的类型。
   produces：指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回

2. @RequestParam：用于获取传入参数的值
   value：参数的名称
   required：定义该传入参数是否必须，默认为true，（和@RequestMapping的params属性有点类似）

3. @PathViriable：用于定义路径参数值 value：参数的名称 required：定义传入参数是否为必须值

4. @ResponseBody：作用于方法上，可以将整个返回结果以某种格式返回，如json或xml格式。

5. @CookieValue：用于获取请求的Cookie值

@RequestMapping("/requestParams.do")
public String requestParams(@CookieValue("JSESSIONID") String cookie){
    return "index";
}  

7. @RequestBody：用于获取请求的对象值
8. @ModelAttribute：用于把参数保存到model中，可以注解方法或参数，注解在方法上的时候，该方法将在处理器方法执行之前执行，然后把返回的对象存放在 session（前提时要有@SessionAttributes注解） 或模型属性中，@ModelAttribute(“attributeName”) 在标记方法的时候指定，若未指定，则使用返回类型的类名称（首字母小写）作为属性名称。

 @ModelAttribute("user")
 public UserEntity getUser(){
     UserEntity userEntityr = new UserEntity();
     userEntityr.setUsername("asdf");
     return userEntityr;
 }

 @RequestMapping("/modelTest.do")
 public String getUsers(@ModelAttribute("user") UserEntity user){
     System.out.println(user.getUsername());
     return "/index";
 }

spring 设计模式

参考地址：https://www.cnblogs.com/AndyAo/p/8666385.html

Spring 作用域

① singleton
使用该属性定义Bean时，IOC容器仅创建一个Bean实例，IOC容器每次返回的是同一个Bean实例。
② prototype
使用该属性定义Bean时，IOC容器可以创建多个Bean实例，每次返回的都是一个新的实例。
③ request
该属性仅对HTTP请求产生作用，使用该属性定义Bean时，每次HTTP请求都会创建一个新的Bean，适用于WebApplicationContext环境。
④ session
该属性仅用于HTTP Session，同一个Session共享一个Bean实例。不同Session使用不同的实例。
⑤ global-session
该属性仅用于HTTP Session，同session作用域不同的是，所有的Session共享一个Bean实例。
下面重点讨论singleton、prototyp作用域，request、session和global-session类作用域放到Spring MVC章节讨论，这里不再做详细讲述。

SpringBean 生命周期

定义Bean 标签的时候 或者@Bean 注解的时候 如果有初始化方法，调用初始化，如果有Scope，执行作用域，如果有销毁方法，则调用销毁方法

spring的事务如何管理

Spring既支持编程式事务管理(也称编码式事务)，也支持声明式的事务管理
编程式事务管理：将事务管理代码嵌入到业务方法中来控制事务的提交和回滚，在编程式事务中，必须在每个业务操作中包含额外的事务管理代码
声明式事务管理：大多数情况下比编程式事务管理更好用。它将事务管理代码从业务方法中分离出来，以声明的方式来实现事务管理。事务管理作为一种横切关注点，可以通过AOP方法模块化。Spring通过Spring AOP框架支持声明式事务管理。
Spring并不直接管理事务，而是提供了多种事务管理器，它们将事务管理的职责委托给JTA或其他持久化机制所提供的平台相关的事务实现。每个事务管理器都会充当某一特定平台的事务实现的门面，这使得用户在Spring中使用事务时，几乎不用关注实际的事务实现是什么。
DataSourceTransactionManager：位于org.springframework.jdbc.datasource包中，数据源事务管理器，提供对单个javax.sql.DataSource事务管理，用于Spring JDBC抽象框架、iBATIS或MyBatis框架的事务管理；
JpaTransactionManager：位于org.springframework.orm.jpa包中，提供对单个javax.persistence.EntityManagerFactory事务支持，用于集成JPA实现框架时的事务管理；
HibernateTransactionManager：位于org.springframework.orm.hibernate3包中，提供对单个org.hibernate.SessionFactory事务支持，用于集成Hibernate框架时的事务管理；该事务管理器只支持Hibernate3+版本，且Spring3.0+版本只支持Hibernate 3.2+版本；

编程事务的代码

https://www.cnblogs.com/chy18883701161/p/11372089.html
https://blog.youkuaiyun.com/qq_29347295/article/details/90903604

SpringBoot 如何处理事务 （声明式事务）

启动类 加上 @EnableTransactionManagement 开启事务
@Transactional 加上业务层的类上代表 这个类所有的方法都要执行事务， 加在方法上事务对当前方法有效

项目中哪些地方用到了事务

一个业务操中涉及到两张表以上（包含两张表）的增删改操作，必须要用事务
example : 权限用户授权 角色授权 下单操作

spring框架中规定 在方法中如果用到了事务 如果想回滚必须抛出一个运行时异常
面试问题 一个方法中有调用了三个方法，我想让第一个方法执行，第二个方法如果出错 第一个方法不会滚，第三个方法继续执行，应该怎么做
1、try catch 处理

try {
    this.delete(wrapper);
    this.insertBatch(roles);
}catch (Exception e){
    e.printStackTrace();
}finally {
    this.deleteById(1);
}

2、手动开启事务

@Service
public class UserRoleServiceImpl extends ServiceImpl<UserRoleMapper, UserRole> implements IUserRoleService {

    @Autowired
    DataSourceTransactionManager transactionManager;
    @Override
    public void add(List<UserRole> roles) {
        Wrapper<UserRole> wrapper = new EntityWrapper<>();
        wrapper.eq("uid",roles.get(0).getUid());

        TransactionStatus status = null;
        try {
            this.delete(wrapper);
            status = transactionManager.getTransaction(new DefaultTransactionDefinition());
            this.insertBatch(roles);
            transactionManager.commit(status);

        }catch (Exception e){
            e.printStackTrace();
            transactionManager.rollback(status);
        }finally {
            this.deleteById(1);
        }

    }
}

事务的特性

1、原子性： 操作要么都成功要么都失败
2、一致性： 操作要么都成功要么都失败
3、隔离性： 事务之间相互独立
4、持久性： 事务执行完，数据永久的保存起来

事务传播行为

传播行为	含义
PROPAGATION_MANDATORY	表示该方法必须在事务中运行，如果当前事务不存在，则会抛出一个异常
PROPAGATION_NESTED	表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。注意各厂商对这种传播行为的支持是有所差异的。可以参考资源管理器的文档来确认它们是否支持嵌套事务
PROPAGATION_NEVER	表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则会抛出异常
PROPAGATION_NOT_SUPPORTED	表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager
PROPAGATION_REQUIRED	表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务
PROPAGATION_REQUIRED_NEW	表示当前方法必须运行在它自己的事务中。一个新的事务将被启动。如果存在当前事务，在该方法执行期间，当前事务会被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager
PROPAGATION_SUPPORTS	表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么该方法会在这个事务中运行

其中PROPAGATION_REQUIRED为默认的传播属性

必须存在的事务
PROPAGATION_REQUIRED
PROPAGATION_REQUIRED_NEW
PROPAGATION_NESTED
PROPAGATION_MANDATORY

必须不存在的事务
PROPAGATION_NEVER　
PROPAGATION_NOT_SUPPORTED

存在也行不存在也行的
PROPAGATION_SUPPORTS

Spring事务的隔离级别

隔离级别定义了一个事务可能受其他并发事务影响的程度。在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发，虽然是必须的，可是会导致下面的问题。
并发事务所导致的问题可以分为以下三类：

① 脏读(Dirty reads)：脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
② 不可重复读(Nonrepeatable read)：不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间更新了数据
③ 幻读(Phantom read)：幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据，接着另一个并发事务(T2)插入了一些数据时。在随后的查询中，第一个事务(T1)就会发现多了一些原本不存在的记录

Spring事务的隔离级别

ISOLATION_DEFAULT：
这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.
另外四个与JDBC的隔离级别相对应
ISOLATION_READ_UNCOMMITTED： 读未提交
这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
这种隔离级别会产生脏读，不可重复读和幻像读。
ISOLATION_READ_COMMITTED： 读已提交 oracle 默认
保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据 （防止脏读）
ISOLATION_REPEATABLE_READ： 可重复读 mysql 默认
这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
ISOLATION_SERIALIZABLE 串行化
这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
除了防止脏读，不可重复读外，还避免了幻像读

脏读

幻读

不可重复读

分布式事务场景

不同服务之间用进行事务控制

分布式事务的实现主要有以下 5 种方案：

• XA 方案
• TCC 方案 用开源框架多一些
• 本地消息表 近几年用的多一些
• 可靠消息最终一致性方案 用mq 做的 大厂用这个比较多
• 最大努力通知方案 分场合用

两阶段提交方案/XA方案

所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。
这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下， 现在微服务，一个大的系统分成几十个甚至几百个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。
分布式事务理论和解决方案：



a.主要业务都在协调服务上处理，比如“下单代码、积分变动代码”的实现，协调服务需要链接积分和订单两个数据库（RM）（微服务中，每个数据库种类不一定一样）。一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。现在微服务，一个大的系统分成几十个甚至几百个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
b.并且不是所有的数据库都支持XA协议。
c.性能很低。
d.如果提交的时候或rollback的时候，RM宕机了…咋办？？？有人又提出方案3PC…那么3pc在最后提交或回滚的时候宕机了咋办？？？？总之有可能最终还是出现问题。

TCC 方案

TCC 的全称是：Try、Confirm、Cancel。

• Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
• Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
• Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）

这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。
比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用 TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。
而且最好是你的各个业务执行的时间都比较短。

https://blog.youkuaiyun.com/yongyou890410/article/details/82719062

本地消息表

本地消息表其实是国外的 ebay 搞出来的这么一套思想。
这个大概意思是这样的：
A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
接着 A 系统将这个消息发送到 MQ 中去；
B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。

可靠消息最终一致性方案

这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。
大概的意思就是：
A 系统先发送一个 prepared 消息到 mq，如果这个 prepared 消息发送失败那么就直接取消操作别执行了；
如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉 mq 发送确认消息，如果失败就告诉 mq 回滚消息；
如果发送了确认消息，那么此时 B 系统会接收到确认消息，然后执行本地的事务；
mq 会自动定时轮询所有 prepared 消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认的消息，是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。
这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。
这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你举用 RocketMQ 支持的，要不你就自己基于类似 ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的。

最大努力通知方案
这个方案的大致意思就是：

• 系统 A 本地事务执行完之后，发送个消息到 MQ；
• 这里会有个专门消费 MQ 的最大努力通知服务，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口；
• 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。

希望阅读完的朋友们,可以给博主点赞+关注,拒绝白嫖,欢迎转载