Spring是一种轻量级开发框架,旨在提高开发人员的开发效率以及系统的可维护性。
我们一般说的Spring框架指的都是Spring Framework,它是很多模块的集合,使用这些模块可以很方便地协助我们进行开发。这些模块是:核心容器、数据访问/集成,Web、AOP(面向切面编程)、工具、消息和测试模块。
比如:Core Container
中的Core
组件是Spring
所有组件的核心,Beans
组件是实现IOC和依赖注入的基础,AOP
组件用来实现面向切面编程。
Spring官网列出的Spring的6个特征:
- 核心技术:依赖注入(DI),AOP,事件(events),资源,i18n,验证,数据绑定,类型转换,SpEL。
- 测试:模拟对象,TestContext框架,Spring MVC测试,WebTestClient。
- Web支持:Spring MVC和Spring WebFlix Web框架。
- 集成:远程处理,JMS,JCA,JMX,电子邮件,任务,调度,缓存。
- 语言:Kotlin,Groovy,动态语言。
列举一些重要的Spring模块
- Spring Core:基础,可以说Spring其他所有功能都需要依赖该库。主要是提供IoC依赖注入功能。
- Spring Aspects:该模块为AspectJ的集成提供支持。
- Spring AOP:提供了面向切面的编程。
- Spring JDBC:Java数据库连接。
- Spring JMS: Java消息服务。
- Spring ORM:用于支持Hibernate等ORM工具。
- Spring Web:为创建Web应用程序提供支持。
- Spring Test:提供了对Junit和TestNG测试的支持。
@RestController vs @Controller
Controller
返回一个页面。
单独使用@Controller
不加@ResponseBody
的话一般使用在要返回一个视图的情况,这种情况属于比较传统的Spring MVC的应用,对应前后端不分离的情况。
@RestController
返回JSON
或XML
形式数据
但@RestController
只返回对象,对象直接以JSON
或XML
形式写入HTTP响应(Response)中,这种情况属于RESTful Web服务,这也是目前日常开发所接触的最常用的情况(前后端分离)。
@Controller
@ResponseBody
返回JSON或XML形式数据。
在Spring 4之前开发RESRful Web服务的话,你需要使用@Controller
并结合@ResponseBody
注解,也就是说@Controller
@ResponseBody
= @RestController
(Spring 4 之后新加的注解)。
@ResponseBody
注解的作用是将Controller
的方法返回的对象通过适当的转换器转换为指定的格式之后,写入到HTTP(响应)对象的Body中,通常用来返回JSON或者XML数据,返回JSON数据的情况比较多。
Spring IOC&AOP的理解 (重要)
Ioc
Ioc(Inverse of Control:控制反转),是一种设计思想。它指的是将原本在程序中手动创建对象的控制权,交由Spring框架来处理。Ioc在其他语言中也有应用,并非Spring特有。IoC容器是Spring用来实现IoC的载体,IOC容器实际上就是个Map(key, value),map中存放的是各种对象。
将对象之间的相互依赖关系交给IoC容器来管理,并由IoC容器完成对象的注入。这样很大程度上可以简化应用的开发,把应用从复杂的依赖关系中解放出来。IoC容器就像是一个工厂一样,当我们需要创建一个对象的时候,只需要配置好配置文件/注解即可,完全不需要考虑对象是如何被创建出来的。
在实际项目中一个Service类可能有几百甚至上千个类作为它的底层,假设我们需要实例化这个Service,你可能每次都需要搞清楚这个Service所有底层类的构造函数,这可能会把人逼疯。如果利用IoC的话,你只需要配置好,然后在需要的地方引用就行了,这大大增加了项目的可维护性且降低了开发难度。
Spring时代我们一般通过XML文件来配置Bean,后来开发人员觉得XML文件来配置不太好,于是SpringBoot注解配置就慢慢开始流行起来。
Spring IoC的初始化过程: XML → rightarrow→ 读取 → rightarrow→ Resource → rightarrow→ 解析 → rightarrow→ BeanDefinition → rightarrow→ 注册 → rightarrow→ BeanFactory
IOC实现原理
使用反射机制 XML技术
当Web容器启动时,Spring的全局Bean管理器会去XML配置文件中扫描的包下面获取到所有的类,并且根据你使用的注解,进行对应的封装,封装到全局的Bean容器中进行管理。一旦容器初始化完毕,BeanID以及Bean的实例化的类对象信息就全部存在了。现在我们需要在某个Service中调用另一个Bean的某个方法时,我们只需要依赖注入进另一个Bean的ID即可,调用的时候Spring去初始化完成的Bean容器中获取即可。如果存在就把依赖的Bean类的实例化对象返回给你。
IOC实现方式
IOC的主要实现方式:依赖查找,依赖注入。依赖注入是一种更可取的方式。
依赖查找,依赖注入的区别?
依赖查找:主要是容器为组件提供一个回调接口和上下文环境。组件必须自己使用容器提供的API来查找资源和协作对象,控制反转仅体现在那些回调方法上,容器调用这些回调方法,应用代码获取到资源。(仅做了解)
依赖注入:组件不做定位查询,只提供标准的Java方法让容器去决定依赖关系,容器全权负责组件的装配,把符合依赖关系的对象通过Java Bean属性或构造方法传递给需要的对象。
Spring依赖注入的方式主要有四个:基于注解注入、Setter注入方式、构造器注入方式,静态工厂注入方式。
基于注解注入:
@Autowired(required=true)
构造器、字段、方法。
Setter注入: 在setter方法内部完成注入。
构造器注入方式: 通过向构造器传参完成注入。
静态工厂注入方式: 通过调用静态工厂来获取自己需要的对象。
AOP
AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关,却为业务模块所共同调用的逻辑或责任(例如事务处理、日志管理、权限控制等)封装起来,便于减少系统的重复代码,降低模块间的耦合度,并且有利于未来的可扩展性和可维护性。
Spring AOP是基于动态代理的,如果要代理的对象,实现了某个接口,那么Spring AOP会使用JDK Proxy,去创建代理对象,而对于没有实现接口的对象,就无法使用JDK Proxy去进行代理了,这时候Spring AOP会使用CGlib
,CGlib
生成一个被代理对象的子类来处理。
也可以使用AspectJ,Spring AOP已经集成了AspectJ,AspectJ 应该算的上是Java生态系统中最完整的AOP框架了。
Spring AOP和AspectJ AOP有什么区别
Spring AOP
属于运行时增强,而AspectJ
属于编译时增强。Spring AOP
基于代理(Proxying)
,而AspectJ
基于字节码操作。
AspectJ AOP
相比于Spring AOP
功能更强大,但是Spring AOP
相对来说更简单。
如果我们的切面比较少,那么两者性能差异不大。但是,当切面太多的话,最多选择AspectJ,它比Spring AOP快很多。
Spring Bean
Java Bean是符合一定规范编写出来的Java类,这些规范包括:
- 类中的所有属性都是私有属性
- 类中必须有一个无参的构造器
- 类中每个属性有其对应的getter和setter方法
- 类实现序列化接口
- 类中可以存在其他方法
Spring中的bean的作用域有哪些?
- singleton:唯一的bean实例,Spring中的bean默认都是单例。
- prototype:每次请求都会创建一个新的bean实例。
- request:每一次HTTP请求都会产生一个新的bean,该bean仅在当前HTTP request内有效。
- session:每一次HTTP请求都会产生一个新的bean,该bean仅在当前HTTP session内有效。
- global-session:全局session作用域,仅仅在基于portlet的web应用中才有意义,Spring5已经没有了。Portlet是能够生产语义代码(例如:HTML)片段的小型Java Web插件。他们基于portlet容器,可以像servlet一样处理HTTP请求,但是,与servet不同,每个portlet都有不同的会话。
Spring中bean的线程安全问题了解吗?
大部分的时候我们并没有在系统中使用多线程,所以很少有人会关注这个问题。单例bean存在线程问题,主要是因为当多个线程操作同一个对象时,对这个对象的非静态成员变量的写操作会存在线程安全问题。
两种解决方式:
- 在Bean对象中尽量避免定义可变的成员变量(不太现实)。
- 在类中定义一个
ThreadLocal
成员变量,将需要的可变成员变量保存在ThreadLocal中(推荐的一种方式)。
@Component
和@Bean
的区别是什么?
3. 作用对象不同:@Component
注解作用于类,而@Bean
注解作用于方法。
4. @Component
通常是通过类路径扫描来自动侦测以及自动装配到Spring容器中(我们可以使用@ComponetScan
注解定义要扫描的路径,从中找出标识了需要装配的类自动装配到Spring的bean容器中)。@Bean
注解通常是我们在标有该注解的方法中定义产生这个bean,@Bean
告诉了Spring这是某个类的实例,当我需要用它的时候还给我。
5. @Bean
注解比@component
注解的自定义性更强,而且很多地方我们只能通过@Bean
注解来注册bean。比如当我们引用第三方库的类需要装配到Spring容器
时,则只能通过@Bean
来实现。
将一个类声明为Spring的bean的注解有哪些?
一般使用@Autowired
注解自动装配bean,要想把类标识成可用于@Autowired
注解自动装配的bean类,采用以下注解可实现:
@Component
:通用的注解,可标注任意类为Spring组件。如果一个Bean不知道属于哪个层,可以使用@Component
注解标注。@Repository
:对应持久层即Dao层,主要用于数据库相关操作。@Service
:对应服务层,主要涉及一些复杂的逻辑,需要用到Dao层。@Controller
:对应Spring MVC控制层,主要用于接收用户请求并调用Service层返回数据给前端页面。
DAO (Data Access Object)
Spring中bean的生命周期?
图片来自Spring中bean的作用域与生命周期。
- 实例化
bean
对象 - 设置对象属性
- 检测
Aware
相关接口并设置相关依赖 BeanPostProcessor
前置处理- 检查是否是
InitializingBean
以决定是否调用afterPropertiesSet
方法 - 检查是否配置有自定义的
init-method
BeanPostProcess
后置处理- 注册必要的
Destruction
相关回调接口 - 使用中
- 是否实现
DisposableBean
接口 - 是否配置有自定义的
destroy
方法
完整的过程参见下图,图片来自Spring实战第四版。
Spring 事件
Spring的核心是ApplicationContext
,它负责管理beans的完整的生命周期。当加载bean时,ApplicationContext
发布某些类型的事件。例如当上下文启动时,ContextStartedEvent
发布;当上下文结束时,ContextStoppedEvent
发布。
通过ApplicationEvent
类和ApplicationListener
接口来提供在ApplicationContext
中处理事件。如果一个bean实现了ApplicationListener
,那么每次ApplicationEvent
被发布到ApplicationContext
上,该bean就会被通知。
Spring内置事件 | 描述 |
---|---|
ContextRefreshedEvent | ApplicationContext被初始化或被刷新时,该事件发布。等价于在ConfigurableApplicationContext接口中调用refresh()方法 |
ContextStartedEvent | 调用ConfigurableApplicationContext接口中的start()方法启动ApplicationContext时,该事件被发布。你可以在此时检查数据库,或者在接收该事件后重启任何停止的应用程序。 |
ContextStoppedEvent | 调用ConfigurableApplicationContext接口的stop()方法时,该事件被发布。你可以在接收这个时间后进行必要的清理工作。 |
ContextClosedEvent | 调用ConfigurableApplicationContext接口的close()方法时,该事件被发布。一个已关闭的上下文到达生命周期末端,它不能被刷新或者重启。 |
RequestHandledEvent | 这是一个web-spefic事件,告诉所有的bean HTTP请求已经被服务 |
由于Spring的事件处理是单线程的,所以如果一个事件被发布,直至并且除非所有的接收者得到该消息,该进程都将阻塞流程不会继续。因此,如果你使用了事件处理,应当注意这一点。
监听上下文事件
为了监听上下文事件,一个bean应该实现ApplicationListener
接口,该接口只有一个onApplicationEvent()
方法。
自定义事件
Spring支持自定义事件,自定义事件要实现如下功能:
- 继承
ApplicationContext
实现自定义事件类(CustomEvent.java) - 实现
ApplicationtionEventPublisherAware
接口实现自定义事件发布类(CustomEventPublisher),包含setApplicationEventPublisher()
方法和publish()
方法。 - 实现
ApplicationListener<CustomEvent>
接口的onApplicationEvent()
方法实现自定义事件处理类CustomEventHandler
最后在主类中创建ConfigurableApplicationContext对象
,使用该对象获取CustomEventPublisher
对象,调用CustomEventPublisher
的publish()
方法。配置文件xml中,需要设置customEventHandler
和CustomEventPublisher
两个bean。
参考:Spring 中的事件处理
Spring Web MVC框架
MVC模式即Model-View-Controller,是经典的应用于应用程序的分层开发模式。
Spring Web MVC提供了模型(model)-视图(view)-控制(control)体系结构用来开发灵活、松散耦合的web应用程序组件。MVC模式能够使得应用程序的不同方面(输入逻辑、业务逻辑、和UI逻辑)的分离,同时也维持了这些元素之间的松散耦合。
- 模型封装了应用程序数据,通常它们由POJO组成。
- 视图主要用于呈现模型数据,并且通常它生成客户端浏览器可以解释的HTML输出。
- 控制器主要用于处理用户请求,并且构建合适的模型并将其传递到视图呈现。
Model - 模型代表一个存取数据的对象或者Java POJO。它可以带有逻辑,在数据变化时更新控制器。
Java POJO (Plain Ordinary Java Object)简单Java对象,实际就是普通的Java Beans,是为了避免和EJB混淆所创造的简称。
View - 视图代表模型包含的数据的可视化。
Controller - 控制器作用与模型和视图上,它控制数据流向模型对象,并在数据变化时更新视图。它使视图与模型分开。
Model1时代:Model1模式下,整个Web应用几乎全部用JSP页面组成,只用少量的JavaBeans来处理数据库连接、访问等操作。这个模式下JSP既是控制层,又是表现层。这种模式存在很多问题。比如:1. 将控制逻辑和表现逻辑混杂在一起,导致代码重用率低。 2.前端和后端相互依赖,难以进行测试并且开发效率极低。
Model2时代:Java Bean(Model) JSP(View) Servlet(Controller),这种开发模式是早期的JavaWeb MVC开发模式。 Model:系统涉及的数据,即dao和bean。View:展示模型中的数据,只是用来展示。Controller:处理用户请求,发送给Model,返回数据给JSP并展示给用户。
MVC是一种非常优秀的设计模式,Spring MVC是一款很优秀的MVC框架。Spring MVC可以帮助我们进行更简洁的Web层开发,并且它天生与Spring框架集成。Spring MVC下我们一般把后端项目分为Service层(处理业务)、DAO层(数据库操作)、Entity层(实体类)、Controller层(控制层,返回数据给前台页面)。
DispatcherServlet
Spring Web模型-视图-控制(MVC)框架是围绕DispatcherServelt
设计的,DispatcherServlet
负责处理所有的HTTP请求和响应。Spring Web MVC DispatcherServlet
请求处理的工作流程如下图所示:
图自Spring Web MVC 框架。
- 收到一个HTTP请求后,
DispatcherServlet
根据HandlerMapping
来选择并且调用适当的控制器。 - 控制器接受请求,并基于使用的GET或POST方法来调用适当的Service方法。Service方法将设置基于定义的业务逻辑的模型数据,并返回视图名称到
DispatcherServlet
。 DispatcherServlet
会从ViewResolver
获取帮助,为请求捡取定义视图。- 一旦确定视图,
DispatcherServlet
将把模型数据传递给视图,最后呈现在浏览器中。
上面所提到的所有组件,即HandlerMapping
、Controller
、
ViewResolver
是WebApplicationContext
的一部分,而WebApplicationContext
是带有一些对web应用程序必要的额外特性的ApplicationContext
的扩展。
Spring MVC详细流程(重要)
- 客户端(浏览器)发送请求,直接请求到
DispatcherServlet
。 DispathcerServlet
根据请求信息调用HandlerMapping
,解析请求对应的Handler
。- 解析到对应的
Handler
(也就是我们平时说的Controller
控制器后),开始由HandlerAdapter
适配器处理。 HandlerAdapter
会根据Handler
来调用真正的处理器处理请求,并处理相应的业务逻辑。- 处理器处理完业务后,会返回一个
ModelAndView
对象,Model
是返回的数据对象,View
是逻辑上的View
。 ViewResolver
会根据逻辑View
查找实际的View
。DispaterServlet
把返回的Model
传给View
(视图渲染)。- 把
View
返回给请求者(浏览器)。
Spring框架中用到了哪些设计模式?
工厂设计模式:Spring使用工厂模式通过BeanFactory
、ApplicagtionContext
创建bean对象。
代理设计模式:Spring AOP功能的实现。
单例设计模式:Spring中的Bean默认是单例的。
包装器设计模式:我们的项目需要连接多个数据库,而且不同的客户在每次访问中根据需要会访问不同的数据库。这种模式让我们可以根据客户的需求动态切换不同的数据源。
观察者模式:Spring事件驱动模型就是观察者模式很经典的一个应用。
适配器模式:SpringAOP的增强或者通知(Advice)使用了适配器模式、Spring MVC中也是用到了适配器模式适配Controller。
Spring事务
Spring管理事务的方式有几种?
- 编程式事务,在代码中硬编码。(不推荐使用)
- 声明式事务,在配置文件中配置 (推荐使用)
声明式事务分为两种:
- 基于XML的声明式事务
- 基于注解的声明式事务
Spring事务中的隔离级别有哪几种?
TranscationDefinition
接口定义了五个隔离级别的常量:
ISOLATION_DEFAULT
:使用后端数据库默认的隔离级别,mysql默认使用的是REPEATABLE_READ
,Oracle默认采用的是READ_COMMITED
隔离级别。ISOLATION_READ_UNCOMMIT
:最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。ISOLATION_READ_COMMIT
:允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。ISOLATION_REPEATABLE_READ
:对同一字段的多次读取结果都是一致的,除非被本身事务自己修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。ISOLATION_SERIALIZABLE
:最高的隔离级别,完全服从ACID的隔离级别。所有事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。这是这将严重影响程序的性能。通常也不会用到该级别。
@Transactional(rollbackFor=Exception.class)
Exception分为运行时异常RuntimeException
和非运行时异常。事务管理对企业级应用来说是至关重要的,即使出现异常情况,也应该保证数据的一致性。
当@Transactional
注解作用于类上时,该类的所有public方法将都具有该类型的事务属性,同时我们可以在方法级别使用该标注来覆盖类级别的定义。如果某个类或者方法加了这个注解,那么类里面的方法抛出异常,就会回滚,数据库里面的数据也会回滚。
在@Transactional
注解中如果不配置rollbackFor
属性,那么事务只会在遇到RuntimeException
时才会回滚,加上rollbackFor=Exception.class
,可以让事务在遇到非运行异常时也回滚。
异常划分 运行时异常/非运行异常 检查异常/非检查异常
RuntimeException
及其子类,以及Error
是非检查异常,其余都是检查异常。
RuntimeException
类及其子类异常都是运行时异常,名字所示。
非运行异常指RuntimeException
以外的异常,类型上都属于Exception及其子类。如果不处理,程序就不能编译通过。
参考
来自JavaGuide,百度可得最新版,这里有精简和修正以及扩充。