Spring
如何实现一个IOC容器
- 配置文件配置包扫描路径
- 递归包扫描获取.class文件
- 反射,确定需要交给IOC管理的类
- 对需要注入的类进行依赖注入
- 配置文件中指定需要扫描的包路径
- 定义一些注解,分别表示访问控制器,业务控制层,数据持久层,依赖注入注解,获取配置文件注解
- 从配置文件中获取需要扫描的包路径,获取到当前路径下的文件信息及文件夹信息,我们将当前路径下所有的以.class结尾的文件添加到一个Set集合中进行存储
- 遍历这个Set集合,获取在类上有指定注解的类,并将其交给IOC容器,定义一个安全的Map来存储这些对象
- 遍历这个IOC容器,获取到每一个类的实例,判断里面是否有依赖其他类的实例,然后注入
Spring是什么
轻量级的开源的J2EE框架,是一个容器框架,用来装javabean(java对象),中间层框架(万能胶)可以起一个连接作用,比如说Mybatis
Spring是一个轻量级的控制反转(IOC)和面向切面(AOP)的容器框架
- 从大小和开销两方面而言Spring都是轻量级的
- 通过控制反转(IOC)的技术达到松耦合的目的
- 提供了面向切面编程的丰富支持,允许通过分离应用的业务逻辑与系统级服务进行内聚性的开发(日志)
- 包含并管理应用对象(Bean)的配置和生命周期,这个意义上是一个容器
- 将简单的组件配置,组合称为复杂的应用,这个意义上是一个框架
谈谈你对AOP的理解
系统是由许多不同的组件所组成的,每一个组件各负责一块特定功能,除了实现自身的核心功能之外,这些组件还经常承担着额外的职责,例如日志,事务管理和安全这样的核心服务经常融入到自身具有的核心业务逻辑的组件上去,这些系统服务经常被称为横切关注点,因为他们会跨越系统的多个组件
当我们需要为分散的对象引入公共行为的时候,OOP则显得无能为力,也就是说,OOP允许你从上到下的关系,但并不适合定义从左到右的关系,例如日志功能
日志代码往往水平地散布在所有对象层次中,而与它所散布到的对象的核心功能毫无关系
在OOP设计中,它导致了大量代码的重复,而不利于各个模块的重用
AOP:将程序的交叉业务逻辑(比如安全,日志,事务等),封装成一个切面,然后注入到目标对象(具体业务逻辑)中去,AOP可以对某个对象或某些对象的功能进行增强,比如对象中的方法进行增强,可以在执行某个方法之前额外的做一些事情,在某个方法执行之后额外的做一些事情
Spring如何通过三级缓存解决循环依赖?为什么不能是两次?
答案链接
- singletonObjects,一级缓存,存储的是所有创建好了的单例Bean
- earlySingletonObjects,完成实例化,但是还未进行属性注入及初始化的对象
- singletonFactories,提前暴露的一个单例工厂,二级缓存中存储的就是从这个工厂中获取到的对象
两次和三次的主要差别在于AOP时代理对象的创建时机,在Bean的生命周期中,AOP是在调用postProcessAfterInitialization时实现的,如果出现了循环依赖,那没有办法,只有给Bean先创建代理,但是没有出现循环依赖的情况下,设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。
谈谈你对IOC的理解
容器概念,控制反转,依赖注入
ioc容器:实际上就是个Map,里面存的是各种对象(xml里配置的bean节点,@repository,@service,@controller,@component),在项目启动的时候会读取配置文件里面的bean节点,根据全限定类名使用反射创建对象放到map里,扫描到打上上述注解的类还是通过反射创建对象放到map里
这个时候map里就有各种对象了,接下来我们在代码里需要用到里面的对象时,再通过DI注入(autowired,resource等注解,xml里bean节点内的ref属性,项目启动的时候会读取xml节点ref属性根据id注入,也会扫描这些注解,根据类型或id注入,id就是对象名)
控制反转:
没有引入IOC容器之前,对象A依赖于对象B,那么对象A在初始化或者运行到某一点的时候,自己必须主动去创建对象B或者使用已经创建的对象B,无论是创建还是使用对象B,控制权都在自己手上.
引入IOC容器之后,对象A和对象B之间失去了直接联系,当对象A运行到需要对象B的时候,IOC容器会主动创建一个对象B注入到对象A需要的地方
通过前后的对比,不难看出,对象A获得依赖对象B的过程,由主动行为变成了被动行为,控制权颠倒过来了
全部对象的控制权全部上缴给"第三方"容器,所以,IOC容器成了整个系统的关键核心,它起到了一种类似"粘合剂"的作用,把系统中的所有对象粘合在一起
BeanFactory和ApplicationContext有什么区别和联系
ApplicationContext是BeanFactory的子接口
ApplicationContext提供了更完整的功能
- 继承MessageSource,因此支持国际化
- 统一的资源文件访问方式
- 提供在监听器中注册bean的事件
- 同时加载多个配置文件
- 载入多个(有继承关系)上下文,使得每一个上下文都专注于一个特定的层次,比如应用的web层
Spring容器初始化实现位置(refresh):AbstractApplicationContext
- BeanFactory采用的是延迟加载形式来注入bean的,即只有在使用到某个bean时(调用getBean()),才对该Bean进行加载实例化,这样,我们就不能发现一些存在的Spring的配置问题,如果Bean的某一个属性没有注入,BeanFactory加载后,直至第一次使用调用getBean方法才抛出异常
- ApplicationContext,它是在容器启动时,一次性创建了所有的bean.这样,在容器启动时,我们就可以发现Spring中存在的配置错误,这样有利于检查所依赖的属性是否注入.ApplicationContext启动后预载入所有的单实例Bean,通过预载入单实例bean,确保当你需要的时候,你就不用等待,因为它们已经创建好了
- 相对于基本的BeanFactory,ApplicationContext唯一的不足是占用内存空间,当应用程序配置Bean较多时,程序启动较慢
- BeanFactory通常以编程的方式被创建,ApplicationContext还能以声明的方式创建,如使用ContextLoader
- BeanFactory和ApplicationContext都支持BeanPostProcessor,BeanFactoryPostProcessor的使用,但两者之间的区别是:BeanFactory需要手动注册,而ApplicationContext则是自动注册
描述Spring Bean的生命周期
- 解析类得到BeanDefinition
- 如果有多个构造方法,则要推断构造方法
- 确定好构造方法后,进行实例化得到一个对象
- 对对象中的加了@Autowired注解的属性进行属性填充
- 回调Aware()方法,比如BeanNameAware,BeanFactoryAware
- 调用BeanPostProcessor的初始化前的方法
- 调用初始化方法
- 调用BeanPostProcessor的初始化后的方法,在这里会进行AOP
- 如果当前创建的bean是单例的,则会把bean放入单例池
- 使用bean
- Spring容器关闭时调用DisposableBean中的destory()方法
解释下Spring支持的几种bean的作用域
- Singleton:默认,每个容器中只有一个bean的实例,单例的模式由BeanFactory自身来维护,该对象的生命周期是与Spring IOC容器一致(但在第一次被注入时才会创建)
- prototype:为每一个bean请求提供一个实例,在每次注入时都会创建一个新的对象
- request:bean被定义为在每个HTPP请求中创建一个单例对象,也就是说在单个请求中都会复用这一个单例对象
- session:与request范围类似,确保每个session中有一个bean的实例,在session过期后,bean会随之失效
- application:bean被定义在ServletContext的生活周期中复用一个单例对象
- websocket:bean被定义为在websocket的生命周期中复用一个单例对象
global-session:全局作用域,global-session和Portlet应用相关.当你的应用部署在Porlet容器中工作时,它包含很多portlet.如果你想要声明让所有的portlet共用全局的存储变量的化,那么这全局变量需要存储在globla-session中,全局作用域与Servlet中的session作用域效果相同
Spring框架中的单例Bean是线程安全的吗?
不安全
Spring中的Bean默认是单例模式的,框架并没有对bean进行多线程的封装处理
如果Bean是有状态的,那就需要开发人员自己来进行线程安全的保证,最简单的方法就是改变bean的作用域,把singleton改为prototype,这样每次请求bean就相当于是new Bean()
- 有状态就是有数据存储功能
- 无状态就是不会保存数据 Controller Service Dao层本身并不是线程安全的,只是如果只是调用里面的方法,而且多线程调用一个实例的方法,会在内存中复制变量,这是自己的线程的工作内存,是安全的
Dao会操作数据库Connection,Connection是带有状态的,比如说数据库事务,Spring的事务管理器使用ThreadLocal为不同线程维护了一套独立的connection副本,保证线程之间不会互相影响(Spring是如何保证事务获取同一个Connection的)
不要在bean中声明任何有状态的实例变量或类变量,如果必须如此,那么就使用ThreadLocal把变量变为线程私有的,如果bean的实例变量或类变量需要在多个线程之间共享,那么就只能使用synchronized,lock,CAS等这些实现线程同步的方法了
Spring中的ThreadLocal
Spring框架中都用到了哪些设计模式
Spring中设计模式
Spring事务的实现方式和原理以及隔离级别
在使用Spring框架时,可以有两种声明事务的方式,一种是编程式的,一种是声明式的,@Transactional注解就是声明式的
首先,事务这个概念是数据库层面的,Spring只是基于数据库中的事务进行了扩展,以及提供了一些能让程序员更加方便地操作事务的方式,
比如我们可以通过在某个方法上增加@Tansaction注解,就可以开启事务,这个方法中所有的sql都会在一个事务中执行,统一成功或失败
在一个方法上加了@Transactional注解后,Spring会基于这个类生成一个代理对象,会将这个代理对象作为bean,当在使用这个代理对象的方法时,如果这个方法上存在@Transaction注解,那么代理逻辑会先把事务的自动提交设置为false,然后再去执行原本的业务逻辑方法,如果执行业务逻辑方法没有出现异常,那么代理逻辑中就会将事务进行提交,如果执行业务逻辑方法出现了异常,那么则会将事务回滚
当然,针对哪些异常回滚事务是可以配置的,可以利用@Transational注解中的rollbackFor属性进行配置,默认情况下会将RuntimeException和Error进行回滚
隔离级别同数据库
Spring默认是read committed,最终以Spring为准,如果Spring级别数据库不支持,那就取决于数据库
Spring事务传播机制
图解Spring事务传播机制
多个事务方法相互调用时,事务如何在这些方法间传播
方法A是一个事务的方法,方法A执行过程中调用了方法B,那么方法B有无事务以及方法B对事务的要求不同都会对方法A的事务具体执行造成影响,同时方法A的事务对方法B的事务执行也会有影响,这种影响具体是声明就由两个方法所定义的事务的传播类型所决定
- REQUIRED(Spring默认的事务传播类型):如果当前没有事务,则自己新建一个事务,如果当前存在事务,则加入这个事务
- SUPPORTS:当前存在事务,则加入当前事务,如果当前没有事务,就以非事务方法执行
- MANDATORY:当前存在事务,则加入当前事务,如果当前事务不存在,则抛出异常
- REQUIRES_NEW:创建一个新事务,如果存在当前事务,则挂起该事务
- NOT_SUPPORTED:以非事务方式执行,如果当前存在事务,则挂起该事务
- NEVER:不使用事务,如果事务存在,则抛出异常
- NESTED:如果当前事务存在,则嵌套事务中执行,否则和REQUIRED的操作一样(子事务中的异常捕获后,父事务不回滚)
Spring事务什么时候会失效
Spring事务的原理是AOP,进行了切面增强,那么失效的根本原因是AOP不起作用了!常见情况有如下几种
- 发生子调用,类里面使用this调用本类的方法 ---->把this改为代理类
- 方法不是public的
- 数据库不支持事务
- 没有被Spring管理
- 异常被吃掉,事务不会回滚
什么是bean的自动装配,有哪些方式
开启自动装配,只需要在xml配置文件中定义"autowire"属性
<bean id = "customer" class="com.xq.Customer" AutoWrie=" "/>
五种装配方式
- no-缺省情况下,自动配置是通过ref属性手动设定
手动装配:以value或ref的方式明确指定属性值都是手动装配
需要通过"ref"属性来连接bean
<bean id="storeService" class="service.StoreServiceImpl">
<property name="orderDao">
<ref bean="orderDao"/>
</property>
<property name="itemDao">
<ref bean="itemDao"/>
</property>
</bean>
- byName-根据bean的属性名称进行自动装配
- byType-根据bean的属性名称进行自动装配
- constructor-类似byType,不过是应用于构造器的参数,如果一个bean与构造器参数的类型相同,则进行自动装配
- autodetect-如果有默认的构造器,通过constructor,否则byType
SpringBoot,SpringMVC,Spring
- Spring是一个IOC容器,用来管理Bean,使用依赖注入实现控制反转,可以很方便的整合各种框架,提供AOP机制弥补OOP代码重复问题,将不同类不同方法中的共同处理抽取成切面,自动主入给方法执行,比如日志,异常等
- SpringMVC是Spring对web框架的一个解决方案,提供了一个总的前端控制器Servlet,用来接受请求,然后定义了一套路由策略(url到handle的映射)及适配执行handle,将handle结果使用视图解析技术生成视图展现给前端
- springboot是spring提供的一个快速开发工具表,简化配置,整合了一系列解决方案
Spring中后置处理器的作用
Spring中的后置处理器分为BeanFactory后置处理器和Bean后置处理器,它们是Spring底层源码架构设计中非常重要的一种机制,同时开发者也可以利用这两种后置处理器来进行扩展.BeanFactory后置处理器标识针对BeanFactory的处理器,Spring启动过程中,会先创建出BeanFactory的实例,然后利用BeanFactory处理器来加工BeanFactory,比如Spring的扫描就是基于BeanFactory后置处理器来实现的
Bean的后置处理器也类似,Spring在创建一个Bean的过程中,首先会实例化得到一个对象,然后再利用Bean后置处理器来对该实例对象进行加工,比如我们常说的依赖注入和AOP
SpringAOP执行顺序
Spring中的5种Aop常见应用方式 - 知乎 Spring4
Around --> Before --> Around(出现异常取消) --> After --> AfterReturning/AfterThrowing
Spring5
Around–>Before–>AfterReturning/AfterThrowing–>After–>Around(出现异常就取消)
SpringMVC
SpringMVC工作流程
- 用户发送请求至前端控制器DispatcherServlet
- DispatcherServlet收到请求调用的HandlerMapping处理器映射器
- 处理器映射器找到具体的处理器(可以根据xml配置,注解进行查找),生成处理器及处理器拦截器(如果有则生成)一并返回给DispatcherServlet
- DispatcherServlet调用HandlerAdapter处理器适配器
- HandlerApapter经过适配调用具体的处理器(Controller)
- Controller执行完成返回ModelAndView
- HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet
- DispatcherServlet将ModelAndView传给ViewResolver视图解析器
- ViewResolver解析后返回View
- DispatcherServlet根据View进行渲染视图
- DispatcherServlet响应用户
SpringMVC的主要组件
- HandlerMapping
根据request找到相应的处理器。因为Handler(Controller)有两种形式,一种是基于类的Handler,另一种是基于Method的Handler(也就是我们常用的) - HandlerAdapter
调用Handler的适配器,因为SpringMVC中handler可以是任意形式,但是Servlet需要的处理方法结构式固定的。如果把Handler(Controller)当做工具的话,那么HandlerAdapter就相当于干活的工人 - HandlerExceptionResolver
对异常的处理 - ViewResolver
用来将String类型的视图名和Locale解析为View类型的视图 - RequestToViewNameTranslator
有的Handler(Controller)处理完后没有设置返回类型,比如是void方法,这是就需要从request中获取viewName - LocalResolver
从request中解析出Locale。Locale表示一个区域,比如zh-cn,对不同的区域的用户,显示不同的结果,这就是i18n(SpringMVC中有具体的拦截器LocaleChangeInterceptor) - ThemeResolver
主题解析,这种类似于我们手机更换主题,不同的UI,css等 - MultipartResolver
处理上传请求,将普通的request封装成MultipartHttpServletRequest - FlashMapManager
用于管理FlashMap,FlashMap用于在redirect重定向中传递参数
SpringMVC中如何解决POST请求中文乱码问题,GET的又如何处理呢?
POST : request.setCharacterEncodingFilter(UTF-8)
web.xml配过滤器
GET:
MyBatis
MyBatis的优缺点
优点
- 基于sql语句编程,相当灵活,不会对应用程序或者数据库的现有设计造成任何影响,SQL写在XML里,解除sql与程序代码的耦合,便于统一管理,提供XML标签,支持编写动态SQL语句,并可重用
- 与JDBC相比,减少了50%以上的代码量,消除了JDBC大量冗余的代码,不需要手动开关连接
- 很好的与各种数据库兼容
- 能够与Spring很好的集成
- 提供映射标签,支持对象与数据库的ORM字段关系映射,提供对象关系映射标签,支持对象关系组件维护
缺点
- SQL语句编写工作量大
- SQL语句依赖于数据库,移植性差
MyBatis与Hibernate有哪些不同
SQL和ORM的争论,永远都不会终止
- 开发速度的对比:
Hibernate的真正掌腥要比Mybatis难些。Mybatis框架相对简单很容易上手,但也相对简陋些。
比起两者的开发速度,不仅仅要考虑到两者的特性及性能,更要根据项目需求去考虑究賁哪一个更适合项目开发,比如:一个项目中用到的复杂查询基本没有,就是简单的增删改查,这样选择hibernate效率就很快了,因为基本的sq|浯句已经被封装好了,根本不需要你去写sql浯句,这就节省了大量的时间,但是对于一个大型项目,复杂浯句较多,这样再去选择hibernate就不是一个太好的选择,选择mybatis就会加快许多,而且句的管理也比较方便。 - 开发工作量的对比:
Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询Mybatis需要手动编写SQL语句,以及ResultMapo而Hibernate有良好的映射机制,开发者无需关心SQL的生成与结果映射可以更专注于业务流程 - sql优化方面:
Hibernate的查询会将表中的所有字段查洵出来,这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段,但这样就破坏Hibernate开发的简洁性。而MybatisfiSQL是手动编写的,所以可以按需求指定查询的字段。
Hibernate HQL语句的调优需要将SQL打出来,而Hibernate的SQL被很多人嫌弃因为太丑了。MyBatis的SQL是自己手动写的所以调整方便。但Hibernate具有自己的日志统计。Mybatis本身不带日志统计,使用Log4j进行日志 - 对象管理的对比:
Hibernate是完整的对象/关系映射解决方案,它提供了对象状态管理(statemanagement)的功能,使开发者不再需要理会底层数据库系统的细节。也就是说相对于见的JDBC/SQL持久层方案中需要管理语句,
Hibernate采用了更自然的面向对象的视角来持久化Java应用中的数据。
换句话说,使用Hibernate的开发者应该总是关注对象的状态(state)不必考虑SQL语句的执行。这部分细节已经由Hibernate掌管妥当,只有开发者在进行系统性能调优的时候才需要进行了解。而MyBatis这一块没有文档说明,用户需要对对象自己进行详细的管理。
#{}和${}的区别是什么
简述Mybatis的插件运行原理,如何编写一个插件?
Mybatis只支持针对ParameterHandler,ResultSetHandler,StatementHandler,Executor这四种接口的插件,Mybatis使用JDK的动态代理,为需要拦截的接口生成代理对象以实现接口方法的拦截功能,每当执行这四种接口对象的方法时,就会进入拦截方法,具体就是InvocationHandler的invoke()方法,拦截那些你指定需要拦截的方法
编写插件:
实现Mybatis的Interceptor接口并复写intercept()方法,然后给插件编写注解,指定要拦截哪一个接口的哪些方法即可,在配置文件中配置编写的插件
Mybatis中当实体类中的属性名和表中的字段名不一样,怎么办?
解决方案
- 写sql语句时起别名
- 在MyBatis的全局配置文件中开启驼峰命名规则
<settings>
<setting name = "mapUnderscoreToCamelCase" value="true"/>
</settings>
- 在Mapper映射文件中使用resultMap来自定义映射规则
- @Results注解
SpringBoot
SpringBoot自动配置原理
如何理解SpringBoot中的starter
什么是嵌入式服务器?为什么要使用嵌入式服务器?
SpringBoot内置tomcat.jar
方便