关于Spring的一些总结

石破天21

已于 2023-07-24 12:39:25 修改

阅读量109

点赞数

CC 4.0 BY-SA版权

文章标签： spring java mybatis

于 2023-06-21 15:21:08 首次发布

本文链接：https://blog.youkuaiyun.com/qq_26798141/article/details/131325928

Autowired和Resource关键字的区别

@Resource和@Autowired都是做bean的注入时使用，其实@Resource并不是Spring的注解，它的包是javax.annotation.Resource，需要导入，但是Spring支持该注解的注入。
1、共同点
两者都可以写在字段和setter方法上。两者如果都写在字段上，那么就不需要再写setter方法。

2、不同点

① @Autowired
@Autowired为Spring提供的注解，需要导入包org.springframework.beans.factory.annotation.Autowired;只按照byType注入。

@Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结合@Qualifier注解一起使用。

注：@Qualifier的作用：

（1）在使用@Autowire自动注入的时候，加上@Qualifier(“test”)可以指定注入哪个对象；
（2）可以作为筛选的限定符，我们在做自定义注解时可以在其定义上增加@Qualifier，用来筛选需要的对象。

（1）的示例

@RestController
public class TestController {

    //此时这两个注解的连用就类似 @Resource(name="testClass1")
    @Autowired
    @Qualifier("testClass1")
    private TestClass testClass;

    @GetMapping("/test")
    public Object test(){
        return testClassList;
    }

}

（2）的示例

@Configuration
public class TestConfiguration {
    //我们调整下在testClass1上增加@Qualifier注解
    @Qualifier
    @Bean("testClass1")
    TestClass testClass1(){
        return new TestClass("TestClass1");
    }

    @Bean("testClass2")
    TestClass testClass2(){
        return new TestClass("TestClass2");
    }
}

@RestController
public class TestController {
    //我们这里使用一个list去接收testClass的对象
    @Qualifier  //这里如果加@Qualifier，testClassList只注入标有Qualifier标签的类，即TestClass1的类，如果没有加，则注入所有TestClass的实例
    @Autowired
    List<TestClass> testClassList= Collections.emptyList();
    
    @GetMapping("/test")
    public Object test(){
        return testClassList;
    }
}

② @Resource
@Resource默认按照ByName自动注入，由J2EE提供，需要导入包javax.annotation.Resource。
@Resource有两个重要的属性：name和type，而Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以，如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性，这时将通过反射机制使用byName自动注入策略。

注：最好是将@Resource放在setter方法上，因为这样更符合面向对象的思想，通过set、get去操作属性，而不是直接去操作属性。
@Resource装配顺序：
①如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常。
②如果指定了name，则从上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常。
③如果指定了type，则从上下文中找到类似匹配的唯一bean进行装配，找不到或是找到多个，都会抛出异常。
④如果既没有指定name，又没有指定type，则自动按照byName方式进行装配；如果没有匹配，则回退为一个原始类型进行匹配，如果匹配则自动装配。
@Resource的作用相当于@Autowired，只不过@Autowired按照byType自动注入。

依赖注入的三种方式

依赖注入：为IOC别名，依赖注入是IOC的实现方式，IOC本质是将对象的创建由程序转移到容器，依赖注入为实现这一目标的方式。

1、构造器注入

2、setter方法注入

3、静态工厂注入

4、实例工厂注入：与静态工厂注入不同的地方在于静态工厂直接通过类就可进行注入，实例工厂需要实例化对象进行注入

spring循环依赖问题如何解决

一级缓存-singletonObjects是用来存放就绪状态的Bean。保存在该缓存中的Bean所实现Aware子接口的方法已经回调完毕，自定义初始化方法已经执行完毕，也经过BeanPostProcessor实现类的postProcessorBeforeInitialization、postProcessorAfterInitialization方法处理；（一级缓存只放单例bean）

二级缓存-earlySingletonObjects是用来存放早期曝光的Bean，一般只有处于循环引用状态的Bean才会被保存在该缓存中。保存在该缓存中的Bean所实现Aware子接口的方法还未回调，自定义初始化方法未执行，也未经过BeanPostProcessor实现类的postProcessorBeforeInitialization、postProcessorAfterInitialization方法处理。如果启用了Spring AOP，并且处于切点表达式处理范围之内，那么会被增强，即创建其代理对象。

这里额外提一点，普通Bean被增强(JDK动态代理或CGLIB)的时机是在AbstractAutoProxyCreator实现的BeanPostProcessor的postProcessorAfterInitialization方法中，而处于循环引用状态的Bean被增强的时机是在AbstractAutoProxyCreator实现的SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法中。

三级缓存-singletonFactories是用来存放创建用于获取Bean的工厂类-ObjectFactory实例。在IoC容器中，所有刚被创建出来的Bean，默认都会保存到该缓存中。

一级缓存是ConcurrentHashMap，二级缓存和三级缓存都是HashMap。

Spring中设计了三级缓存来解决循环依赖问题，当我们去调用getBean()方法的时候，Spring会先从一级缓存中去找到目标Bean，如果发现一级缓存中没有便会去二级缓存中去找，而如果一、二级缓存中都没有找到，意味着该目标Bean还没有实例化。于是，Spring容器会实例化目标Bean（PS：刚初始化的Bean称为早期Bean），然后，将目标Bean放入到二级缓存中，同时，加上标记是否存在循环依赖。如果不存在循环依赖便会将目标Bean存入到二级缓存，否则，便会标记该Bean存在循环依赖，然后将等待下一次轮询赋值，也就是解析@Autowired注解。等@Autowired注解赋值完成后（PS：完成赋值的Bean称为成熟Bean），会将目标Bean存入到一级缓存。总结一下，Spring一级缓存中存放所有的成熟Bean，二级缓存中存放所有的早期Bean，先取一级缓存，再去二级缓存。

Bean在一级缓存、二级缓存、三级缓存中的流转顺序为：三级缓存->二级缓存->一级缓存。但是并不是所有Bean都会经历这个过程，例如对于原型Bean(Prototype)，IoC容器不会将其保存到任何一个缓存中的，另外即便是单例Bean(Singleton)，如果没有循环引用关系，也不会被保存到二级缓存中的。

为什么需要二级缓存

没有代理的时候，只用到一、三级缓存。

1、如果没有涉及到AOP代理，二级缓存好像显得有点多余。但是如果使用了AOP代理，那么二级缓存就发挥作用了，我们都知道Bean的AOP动态代理创建是在初始化之后，但是循环依赖的Bean如果使用了AOP增强，就无法等到解决完循环依赖后再创建代理对象，因为这个时候已经需要注入属性，所以如果循环依赖的Bean使用了AOP，需要提前创建出代理对象出来，然后放入二级缓存中。

2、前面提到，三级缓存中存放的是ObjectFactory对象工厂，当执行ObjectFactory＃getObject（）回调的时候，实际上会执行 getEarlyBeanReference（）方法获取bean的早期引用，但是我们

需要注意的是，每次执行Objectractory＃getObject（）方法都会重新产生一个新的代理对象，这就有问题了，因为我们的bean是单例的，不可能每次都来一个新的代理对象。

3、所以，Spring引入了二级缓存来解决这个问题，将执行了ObjectFactory＃getObject（）产生的对象放到二级缓存中，后面我们可以从二级缓存中拿，没必要再执行一遍ObjectFactory＃getObject（）方法再产生一个新的代理对象，保证始终只有一个代理对象。

Spring中哪些情况不能解决循环依赖问题

1.多例Bean通过setter注入的情况，不能解决循环依赖问题

2.构造器注入的Bean的情况，不能解决循环依赖问题

3.单例的代理Bean通过Setter注入的情况，不能解决循环依赖问题

4.设置了@DependsOn的Bean的情况，不能解决循环依赖问题

springMVC

一种设计模式，是spring的一个子模块

M-Model 模型（完成业务逻辑：有javaBean构成，service+dao+entity）
V-View 视图（做界面的展示 jsp，html……）
C-Controller 控制器（接收请求—>调用模型—>根据结果派发页面）

工作原理：

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响应用户。

涉及的组件：

1、前端控制器DispatcherServlet（不需要工程师开发）,由框架提供作用：接收请求，响应结果，相当于转发器，中央处理器。有了dispatcherServlet减少了其它组件之间的耦合度。用户请求到达前端控制器，它就相当于mvc模式中的c，dispatcherServlet是整个流程控制的中心，由它调用其它组件处理用户的请求，dispatcherServlet的存在降低了组件之间的耦合性。

2、处理器映射器HandlerMapping(不需要工程师开发),由框架提供作用：根据请求的url查找Handler HandlerMapping负责根据用户请求找到Handler即处理器，springmvc提供了不同的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。

HandlerMapping告诉HandlerExecutionChain应该执行的handler的类型。

HandlerMapping以及HandlerAdapter的类型有很多种：

1、用注解@RequestMapping定义的Handler（org.springframework.web.method.HandlerMethod），用的是RequestMappingHandlerMapping以及RequestMappingHandlerAdapter

2、静态资源的请求，用的是SimpleUrlHandlerMapping以及SimpleControllerHandlerAdapter

3、通过org.springframework.web.servlet.mvc.Controller和org.springframework.web.HttpRequestHandler实现的Handler，用的是BeanNameUrlHandlerMapping以及HttpRequestHandlerAdapter

注：org.springframework.web.HttpRequestHandler比org.springframework.web.servlet.mvc.Controller更原生，两者的唯一不同的是return null。那是因为HttpRequestHandler#handleRequest()它没有返回值，这就需要全靠开发者自己写response，而org.springframework.web.servlet.mvc.Controller最起码来说还有Model和View自动渲染的能力。

3、处理器适配器HandlerAdapter 作用：按照特定规则（HandlerAdapter要求的规则）去执行Handler 通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。

Spring MVC的Handler（Controller接口，HttpRequestHandler，@RequestMapping、Servlet）有多种表现形式，不同的Handler，处理请求的方式是不一样的，注解@RequestMapping方式使用的是用方法处理请求，而实现Controller接口和HttpRequestHandler接口方式使用的是一个类，而适配器模式就能模糊掉具体的实现，从而就能提供统一访问接口，所以这地方就要使用适配器了。

HandlerMapping的源码也说明了这一点。HandlerMapping接口里面只有一个getHandler()方法，而且返回类型是HandlerExecutionChain，用HandlerExecutionChain里面定义了一个Object类型的handler属性，并对handler进行了封装，在每个请求里加入了拦截器链。然后将这个HandlerExecutionChain里面的handler传给了HandlerAdapter。

4、处理器Handler(需要工程师开发) 注意：编写Handler时按照HandlerAdapter的要求去做，这样适配器才可以去正确执行Handler Handler 是继DispatcherServlet前端控制器的后端控制器，在DispatcherServlet的控制下Handler对具体的用户请求进行处理。由于Handler涉及到具体的用户业务请求，所以一般情况需要工程师根据业务需求开发Handler。

5、视图解析器View resolver(不需要工程师开发),由框架提供作用：进行视图解析，根据逻辑视图名解析成真正的视图（view） View Resolver负责将处理结果生成View视图，View Resolver首根据逻辑视图名解析成物理视图名即具体的页面地址，再生成View视图对象，最后对View进行渲染将处理结果通过页面展示给用户。 springmvc框架提供了很多的View视图类型，包括：jstlView、freemarkerView、pdfView等。一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户，需要由工程师根据业务需求开发具体的页面。

6、视图View(需要工程师开发jsp...) View是一个接口，实现类支持不同的View类型（jsp、freemarker、pdf...）

Spring AOP和AspectJ的区别

Spring AOP也是对目标类增强，生成代理类。但是与AspectJ的最大区别在于---Spring AOP的运行时增强，而AspectJ是编译时增强。曾经以为AspectJ是Spring AOP一部分，是因为Spring AOP使用了AspectJ的Annotation。使用了Aspect来定义切面,使用Pointcut来定义切入点，使用Advice来定义增强处理。虽然使用了Aspect的Annotation，但是并没有使用它的编译器和织入器。其实现原理是JDK 动态代理，在运行时生成代理类。

AOP 代理 = 原来的业务类+增强处理。这个生成AOP 代理由 Spring 的 IoC 容器负责生成。也由 IoC 容器负责管理。因此，AOP 代理可以直接使用容器中的其他 Bean 实例作为目标，这种关系可由 IoC 容器的依赖注入提供。

"增强"在spring框架里的意思是向各个程序内部注入一些逻辑代码从而增强原有程序的功能。

@annotation @within @execution的区别

@annotation：匹配有指定注解的方法（注解作用在方法上面）

@within：有指定注解的类中的所有方法都会被拦截（判断被调用的方法所属的类中是否声明了注解A，如果有，会被拦截）

@execution：拦截任意包、类、方法，看具体正则写法，拦截范围比较广

spring bean的生命周期

Servlet的生命周期：实例化，初始init，接收请求service，销毁destroy；

Spring上下文中的Bean生命周期也类似，如下：

（1）实例化Bean：对于BeanFactory容器，当客户向容器请求一个尚未初始化的bean时，或初始化bean的时候需要注入另一个尚未初始化的依赖时，容器就会调用createBean进行实例化。对于ApplicationContext容器，当容器启动结束后，通过获取BeanDefinition对象中的信息，实例化所有的bean。

（2）设置对象属性（依赖注入）：实例化后的对象被封装在BeanWrapper对象中，紧接着，Spring根据BeanDefinition中的信息以及通过BeanWrapper提供的设置属性的接口完成依赖注入。（一般都是非spring体系标识的属性）

注：BeanWrapper是对Bean的包装，其接口中所定义的功能很简单包括设置获取被包装的对象，获取被包装bean的属性描述器，由于BeanWrapper接口是PropertyAccessor的子接口，因此其也可以设置以及访问被包装对象的属性值。BeanWrapper大部分情况下是在spring ioc内部进行使用，通过BeanWrapper,spring ioc容器可以用统一的方式来访问bean的属性。用户很少需要直接使用BeanWrapper进行编程。

（3）处理Aware接口：接着，Spring会检测该对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给Bean：

①如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(StringbeanId)方法，此处传递的就是Spring配置文件中Bean的id值；

②如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()方法，传递的是Spring工厂自身。

③如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文；

（4）BeanPostProcessor：如果想对Bean进行一些自定义的处理，那么可以让Bean实现了BeanPostProcessor接口，那将会调用postProcessBeforeInitialization(Object obj, String s)方法。

（5）InitializingBean 与 init-method：如果Bean在Spring配置文件中配置了 init-method 属性，则会自动调用其配置的初始化方法。

（6）如果这个Bean实现了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；由于这个方法是在Bean初始化结束时调用的，所以可以被应用于内存或缓存技术；以上几个步骤完成后，Bean就已经被正确创建了，之后就可以使用这个Bean了。

（7）DisposableBean：当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用其实现的destroy()方法；

（8）destroy-method：最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。

注：

singleton为单例模式，即scope="singleton"的bean，在容器中，只实例化一次。（预先实例化）

prototype即原型模式，调用多少次bean，就实例化多少次。（调用时实例化）

spring bean的作用域

1. singleton：在容器中，只实例化一次。

2. prototype：调用多少次bean，就实例化多少次。对于有状态的Bean应该使用prototype，对于无状态的Bean则使用singleton

3. request：每次的Http请求，Spring容器会根据相关的Bean的定义来创建一个全新的Bean实例。而且该Bean只在当前request内是有效的。

4. session：针对一次session建立bean(一个session可能会有多个http请求)

5. global session：类似标准的http session作用域，不过仅仅在基于portlet的web应用当中才有意义。

BeanFactory和ApplicationContext的联系和区别

Spring 框架带有两个 IOC 容器—— BeanFactory和ApplicationContext。BeanFactory是 IOC 容器的最基本版本，ApplicationContext扩展了BeanFactory的特性。

ApplicationContext是BeanFactory的子接口。spring IOC的容器实现本质是beanfactory,其底层实现类是DefaultListableBeanFactory。

XmlBeanFactory继承自DefaultListableBeanFactory，重写了一些功能。

BeanFactory的结构图

区别：

1、BeanFactory按需加载 bean，而ApplicationContext在启动时加载所有 bean。BeanFactory比ApplicationContext轻量，BeanFactory支持延迟加载。

2、ApplicationContext会自动注册BeanFactoryPostProcessor和BeanPostProcessor，BeanFactory不会。如果使用的是普通的BeanFactory，那么事务和 AOP 等功能将不会生效（不编写额外的代码情况下）

总结：

1、BeanFactory负责读取bean配置文档，管理bean的加载，实例化，维护bean之间的依赖关系，负责bean的声明周期。

2、ApplicationContext除了提供上述BeanFactory所能提供的功能之外，还提供了更完整的框架功能：
a. 国际化支持（MessageSource接口）
b. 资源访问：Resource rs = ctx. getResource(“classpath:config.properties”), “file:c:/config.properties”
c. 事件传递：通过实现ApplicationContextAware接口。

spring事务和数据库事务的关系（待补充）

spring事务是基于springAOP来实现的

spring事务的传播级别

1. PROPAGATION_REQUIRED:默认的Spring事物传播级别，若当前存在事务，则加入该事务，若不存在事务，则新建一个事务。

2. PAOPAGATION_REQUIRE_NEW:若当前没有事务，则新建一个事务。若当前存在事务，则新建一个事务，新老事务相互独立。外部事务抛出异常回滚不会影响内部事务的正常提交。

3. PROPAGATION_NESTED:如果当前存在事务，则嵌套在当前事务中执行。如果当前没有事务，则新建一个事务，类似于REQUIRE_NEW。（是指如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于 REQUIRED）

4. PROPAGATION_SUPPORTS:支持当前事务，若当前不存在事务，以非事务的方式执行。

5. PROPAGATION_NOT_SUPPORTED:以非事务的方式执行，若当前存在事务，则把当前事务挂起。

6. PROPAGATION_MANDATORY:强制事务执行，若当前不存在事务，则抛出异常.

7. PROPAGATION_NEVER:以非事务的方式执行，如果当前存在事务，则抛出异常。

Spring事务传播级别一般不需要定义，默认就是PROPAGATION_REQUIRED，除非在嵌套事务的情况下需要重点了解。

注：加入事务（REQUIRED）和嵌套事务（NESTED）都是事务传播机制的两种传播级别，如果当前不存在事务，那么二者的行为是一样的；但如果当前存在事务，那么加入事务的事务传播级别在遇到异常之后，会将事务全部回滚；而嵌套事务在遇到异常时，只是执行了部分事务的回滚。嵌套事务只所以能实现部分事务的回滚，是因为在数据库中存在一个保存点（savepoint）的概念，以 MySQL 为例，嵌套事务相当于新建了一个保存点，而滚回时只回滚到当前保存点，因此之前的事务是不受影响的。

@Transactional 的使用注意事项总结
1）@Transactional 注解只有作用到 public 方法上事务才生效，不推荐在接口上使用；
2）避免同一个类中调用 @Transactional 注解的方法，这样会导致事务失效；
3）正确的设置 @Transactional 的 rollbackFor 和 propagation 属性，否则事务可能会回滚失败;
4）被 @Transactional 注解的方法所在的类必须被 Spring 管理，否则不生效；
5）底层使用的数据库必须支持事务机制，否则不生效。