1、如何实现一个IOC容器
IoC(Inversion of Control),意为控制反转,不是什么技术,而是一种设计思想。Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。
2、spring是什么?
Spring是一个开源的轻量级的Java开发框架。
①IOC容器
Java思想是面向对象的开发,一个应用程序是由一组对象通过相互协作开发出的业务逻辑组成,那么如何管理这些对象,使他们高效地协作呢?抽象工厂、工厂方法设计模式”可以帮我们创建对象,“生成器模式”帮我们处理对象间的依赖关系,不也能完成这些功能吗?可是这些又需要我们创建另一些工厂类、生成器类,我们又要而外管理这些类,增加了我们的负担。所以用另外的方式,如果对象需要的时候,就自动地生成对象,不用再去创建。
Spring提出了一种思想:就是由spring来负责控制对象的生命周期和对象间的关系。所有的类都会在spring容器中登记,告诉spring你是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象都被spring控制,所以这叫控制反转(IOC)。
② AOP
比如进行一个计算器的编写,需要实现加、减、乘、除四种简单的运算,编写四种不同的方法。还有另外的两个需求是在每种运算之前和运算之后需要打印日志进行记录,需要进行数字合规的校验。我们就得考虑如何能简单地实现呢?就是得把日志记录和数据校验等可重用的功能模块分离出来,然后在程序的执行的合适的地方动态地植入这些代码并执行。这样就简化了代码的书写,业务逻辑代码中没有参和通用逻辑的代码,业务模块更简洁,只包含核心业务代码。实现了业务逻辑和通用逻辑的代码分离,便于维护和升级,降低了业务逻辑和通用逻辑的耦合。
有人会想到把这些通用的功能整合到一个方法中,去调用,这样也是避免不了重复调用,并且在业务逻辑中添加额外的代码。Spring通过配置的方式,而且不需要在业务逻辑代码中添加任何额外代码,就可以很好地实现上述功能。以上这种方式就是spring中实现的AOP:意思是面向切面编程,提供从另一个角度来考虑程序结构以完善面向对象编程(相对于OOP),即可以通过在编译期间、装载期间或运行期间实现在不修改源代码的情况下给程序动态添加功能的一种技术。通俗点说就是把可重用的功能提取出来,然后将这些通用功能在合适的时候织入到应用程序中;比如安全,日记记录,这些都是通用的功能,我们可以把它们提取出来,然后在程序执行的合适地方织入这些代码并执行它们,从而完成需要的功能并复用了这些功能。
③声明式事务
通过编程的方式对事务进行管理,特别麻烦。在Spring中,我们可以从单调烦闷的事务管理代码中解脱出来,通过声明式方式灵活地进行事务的管理,提高开发效率和质量。
④粘合剂
Spring是一个超级粘合平台,除了自己提供功能外,还提供粘合其他技术和框架的能力,从而使我们可以更自由的选择到底使用什么技术进行开发。
3、谈谈你对AOP的理解
系统是由许多不同的组件所组成的,每一个组件各负责一块特定功能。除了实现自身核心功能之外,这些组件还经常承担着额外的职责。例如日志、事务管理和安全这样的核心服务经常融入到自身具有核心业务逻辑的组件中去。这些系统服务经常被称为横切关注点,因为它们会跨越系统的多个组件。
当我们需要为分散的对象引入公共行为的时候,OOP则显得无能为力。也就是说,OOP允许你定义从 上到下的关系,但并不适合定义从左到右的关系。例如日志功能。
日志代码往往水平地散布在所有对象层次中,而与它所散布到的对象的核心功能毫无关系。
在OOP设计中,它导致了大量代码的重复,而不利于各个模块的重用。
AOP:将程序中的交叉业务逻辑(比如安全,日志,事务等),封装成一个切面,然后注入到目标对象(具体业务逻辑)中去。AOP可以对某个对象或某些对象的功能进行增强,比如对象中的方法进行增强,可以在执行某个方法之前额外的做一些事情,在某个方法执行之后额外的做一些事情
4、谈谈你对IOC的理解
Java思想是面向对象的开发,一个应用程序是由一组对象通过相互协作开发出的业务逻辑组成,那么如何管理这些对象,使他们高效地协作呢?抽象工厂、工厂方法设计模式”可以帮我们创建对象,“生成器模式”帮我们处理对象间的依赖关系,不也能完成这些功能吗?可是这些又需要我们创建另一些工厂类、生成器类,我们又要而外管理这些类,增加了我们的负担。所以用另外的方式,如果对象需要的时候,就自动地生成对象,不用再去创建。
Spring提出了一种思想:就是由spring来负责控制对象的生命周期和对象间的关系。所有的类都会在spring容器中登记,告诉spring你是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象都被spring控制,所以这叫控制反转(IOC)。
5、BeanFactory和ApplicationContext有什么区别?
BeanFactory:
是Spring里面最低层的接口,提供了最简单的容器的功能,只提供了实例化对象和拿对象的功能;
ApplicationContext:
应用上下文,继承BeanFactory接口,它是Spring的一各更高级的容器,提供了更多的有用的功能;
1) 国际化(MessageSource)
2) 访问资源,如URL和文件(ResourceLoader)
3) 载入多个(有继承关系)上下文 ,使得每一个上下文都专注于一个特定的层次,比如应用的web层
4) 消息发送、响应机制(ApplicationEventPublisher)
5) AOP(拦截器)
BeanFactory 和ApplicationContext (详细说明)
Bean 工厂(com.springframework.beans.factory.BeanFactory)是Spring 框架最核心的接口,它提供了高级IoC 的配置机制。
应用上下文(com.springframework.context.ApplicationContext)建立在BeanFactory 基础之上。
几乎所有的应用场合我们都直接使用ApplicationContext 而非底层的BeanFactory。
1.1 BeanFactory 的类体系结构
BeanFactory: 接口位于类结构树的顶端, 它最主要的方法就是getBean(StringbeanName),该方法从容器中返回特定名称的Bean,BeanFactory 的功能通过其他的接口得到不断扩展。
ListableBeanFactory:该接口定义了访问容器中Bean 基本信息的若干方法,如查看Bean 的个数、获取某一类型Bean 的配置名、查看容器中是否包括某一Bean 等方法;
HierarchicalBeanFactory:父子级联IoC 容器的接口,子容器可以通过接口方法访问父容器;
ConfigurableBeanFactory:是一个重要的接口,增强了IoC 容器的可定制性,它定义了设置类装载器、属性编辑器、容器初始化后置处理器等方法;
AutowireCapableBeanFactory:定义了将容器中的Bean 按某种规则(如按名字匹配、按类型匹配等)进行自动装配的方法;
SingletonBeanRegistry:定义了允许在运行期间向容器注册单实例Bean 的方法;
BeanDefinitionRegistry:Spring 配置文件中每一个<bean>节点元素在Spring 容器里都通过一个BeanDefinition 对象表示,它描述了Bean 的配置信息。而BeanDefinitionRegistry 接口提供了向容器手工注册BeanDefinition 对象的方法。
1.2 ApplicationContext 的类体系结构
ApplicationContext 由BeanFactory 派生而来,提供了更多面向实际应用的功能。在BeanFactory 中,很多功能需要以编程的方式实现,而在ApplicationContext 中则可以通过配置的方式实现。
ApplicationContext 的主要实现类是ClassPathXmlApplicationContext 和FileSystemXmlApplicationContext,前者默认从类路径加载配置文件,后者默认从文件系统中装载配置文件。
核心接口包括:
ApplicationEventPublisher:让容器拥有发布应用上下文事件的功能,包括容器启动事件、关闭事件等。实现了ApplicationListener 事件监听接口的Bean 可以接收到容器事件, 并对事件进行响应处理。在ApplicationContext 抽象实现类AbstractApplicationContext 中,我们可以发现存在一个ApplicationEventMulticaster,它负责保存所有监听器,以便在容器产生上下文事件时通知这些事件监听 者。
MessageSource:为应用提供i18n 国际化消息访问的功能;
ResourcePatternResolver : 所有ApplicationContext 实现类都实现了类似于PathMatchingResourcePatternResolver 的功能,可以通过带前缀的Ant 风格的资源文件路径装载Spring 的配置文件。
LifeCycle:该接口是Spring 2.0 加入的,该接口提供了start()和stop()两个方法,主要用于控制异步处理过程。在具体使用时,该接口同时被 ApplicationContext 实现及具体Bean 实现,ApplicationContext 会将start/stop 的信息传递给容器中所有实现了该接口的Bean,以达到管理和控制JMX、任务调度等目的。
ConfigurableApplicationContext 扩展于ApplicationContext,它新增加了两个主要的方法:refresh()和close(),让ApplicationContext 具有启动、刷新和关闭应用上下文的能力。在应用上下文关闭的情况下调用refresh()即可启动应用上下文,在已经启动的状态下,调用 refresh()则清除缓存并重新装载配置信息,而调用close()则可关闭应用上下文。这些接口方法为容器的控制管理带来了便利.
6.描述一下Spring Bean的生命周期?
1. 实例化Bean对于BeanFactory容器,当客户向容器请求一个尚未初始化的bean时,或初始化bean的时候需要注入另一个尚未初始化的依赖时,容器就会调用createBean进行实例化。 对于ApplicationContext容器,当容器启动结束后,便实例化所有的bean。 容器通过获取BeanDefinition对象中的信息进行实例化。并且这一步仅仅是简单的实例化,并未进行依赖注入。 实例化对象被包装在BeanWrapper对象中,BeanWrapper提供了设置对象属性的接口,从而避免了使用反射机制设置属性。
2. 设置对象属性(依赖注入)实例化后的对象被封装在BeanWrapper对象中,并且此时对象仍然是一个原生的状态,并没有进行依赖注入。 紧接着,Spring根据BeanDefinition中的信息进行依赖注入。 并且通过BeanWrapper提供的设置属性的接口完成依赖注入。
3. 注入Aware接口紧接着,Spring会检测该对象是否实现了xxxAware接口,并将相关的xxxAware实例注入给bean。
4. BeanPostProcessor当经过上述几个步骤后,bean对象已经被正确构造,但如果你想要对象被使用前再进行一些自定义的处理,就可以通过BeanPostProcessor接口实现。 该接口提供了两个函数:postProcessBeforeInitialzation( Object bean, String beanName ) 当前正在初始化的bean对象会被传递进来,我们就可以对这个bean作任何处理。 这个函数会先于InitialzationBean执行,因此称为前置处理。 所有Aware接口的注入就是在这一步完成的。postProcessAfterInitialzation( Object bean, String beanName ) 当前正在初始化的bean对象会被传递进来,我们就可以对这个bean作任何处理。 这个函数会在InitialzationBean完成后执行,因此称为后置处理。
5. InitializingBean与init-method当BeanPostProcessor的前置处理完成后就会进入本阶段。 InitializingBean接口只有一个函数:afterPropertiesSet()这一阶段也可以在bean正式构造完成前增加我们自定义的逻辑,但它与前置处理不同,由于该函数并不会把当前bean对象传进来,因此在这一步没办法处理对象本身,只能增加一些额外的逻辑。 若要使用它,我们需要让bean实现该接口,并把要增加的逻辑写在该函数中。然后Spring会在前置处理完成后检测当前bean是否实现了该接口,并执行afterPropertiesSet函数。当然,Spring为了降低对客户代码的侵入性,给bean的配置提供了init-method属性,该属性指定了在这一阶段需要执行的函数名。Spring便会在初始化阶段执行我们设置的函数。init-method本质上仍然使用了InitializingBean接口。
6. DisposableBean和destroy-method和init-method一样,通过给destroy-method指定函数,就可以在bean销毁前执行指定的逻辑。
7、解释下Spring支持的几种bean的作用域。
singletion:默认,每个容器只能有一个bean的实例,单例模式由BeanFactory自身来维护。该对象的生命周期是与Spring IOC容器一致的(但在第一次被注入时才会创建)
prototype:为每一个bean请求提供一个实例。在每次注入时都会创建一个新的对象
request:bean被定义为在每个http请求中创建一个单例对象,也就是说在单个请求中都会复用这一单例对象
session:与request范围类似,确保每个session中都只有一个bean的实例,在session过期后,bean会随之失效
application:bean被定义在ServletContext的生命周期中复用的一个单例对象
websocket:bean被定义为在websocket的生命周期中复用的一个单例对象
8、Spring框架中的单例Bean是线程安全的么?
Spring框架并没有对单例bean进行任何多线程的封装处理。关于单例bean的线程安全和并发问题需要开发者自行去搞定。 但实际上,大部分的Spring bean并没有可变的状态(比如Service类和DAO类),所以在某种程度上说Spring的单例bean是线程安全的。如果你的bean有多种状态的话(比如 View Model 对象),就需要自行保证线程安全。
最浅显的解决办法就是将多态bean的作用域由 “singleton” 变更为 “prototype”,让每一个线程都能拥有一个实例,这样就不会让多线程并发的时候共同操作一个实例而导致脏数据的问题
9、Spring 框架中都用到了哪些设计模式?
1、工厂模式:BeanFactory就是简单工厂模式的体现,用来创建对象的实例;
2、单例模式:Bean默认为单例模式。
3、代理模式:Spring的AOP功能用到了JDK的动态代理
和CGLIB字节码生成技术;
4、模板方法:用来解决代码重复的问题。
比如. RestTemplate, JmsTemplate, JpaTemplate。
5、观察者模式:定义对象键一种一对多的依赖关系,
当一个对象的状态发生改变时,所有依赖于它的对象都会得 到通知被制动更新,如Spring中listener的实现–ApplicationListener
10、Spring事务的实现方式和原理以及隔离级别?
Spring 事务的本质其实就是数据库对事务的支持,没有数据库的事务支持,
spring 是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过
binlog 或者 redo log 实现的。
Spring 的事务传播行为:
Spring 事务的传播行为说的是,当多个事务同时存在的时候, Spring 如何
处理这些事务的行为。
① PROPAGATION_REQUIRED:如果当前没有事务,就创建一个新事务,
如果当前存在事务,就加入该事务,该设置是最常用的设置。
② PROPAGATION_SUPPORTS:支持当前事务,如果当前存在事务,就
加入该事务,如果当前不存在事务,就以非事务执行。‘
③ PROPAGATION_MANDATORY:支持当前事务,如果当前存在事务,
就加入该事务,如果当前不存在事务,就抛出异常。
④ PROPAGATION_REQUIRES_NEW:创建新事务,无论当前存不存在事
务,都创建新事务。
⑤ PROPAGATION_NOT_SUPPORTED:以非事务方式执行操作,如果当
前存在事务,就把当前事务挂起。
⑥ PROPAGATION_NEVER: 以非事务方式执行,如果当前存在事务,则
抛出异常。
⑦ PROPAGATION_NESTED:如果当前存在事务,则在嵌套事务内执行。
如果当前没有事务,则按 REQUIRED 属性执行
Spring 中的隔离级别:
① ISOLATION_DEFAULT:这是个 PlatfromTransactionManager 默认的隔离级别,
使用数据库默认的事务隔离级别。
② ISOLATION_READ_UNCOMMITTED:读未提交,允许另外一个事务可以看到这个
事务未提交的数据。
③ ISOLATION_READ_COMMITTED:读已提交,保证一个事务修改的数据提交后才
能被另一事务读取,而且能看到该事务对已有记录的更新。
④ ISOLATION_REPEATABLE_READ:可重复读,保证一个事务修改的数据提交后才
能被另一事务读取,但是不能看到该事务对已有记录的更新。
⑤ ISOLATION_SERIALIZABLE:一个事务在执行的过程中完全看不到其他事务对数据
库所做的更新。
11、spring事务传播机制
1、什么是事务的传播?
简单的理解就是多个事务方法相互调用时,事务如何在这些方法间传播。
2、Spring事务传播类型枚举Propagation介绍
在Spring中对于事务的传播行为定义了七种类型分别是:REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED。
在Spring源码中这七种类型被定义为了枚举。源码在org.springframework.transaction.annotation包下的Propagation,源码中注释很多,对传播行为的七种类型的不同含义都有解释,后文中锤子我也会给大家分析,我在这里就不贴所有的源码,只把这个类上的注解贴一下,翻译一下就是:表示与TransactionDefinition接口相对应的用于@Transactional注解的事务传播行为的枚举。
也就是说枚举类Propagation是为了结合@Transactional注解使用而设计的,这个枚举里面定义的事务传播行为类型与TransactionDefinition中定义的事务传播行为类型是对应的,所以在使用@Transactional注解时我们就要使用Propagation枚举类来指定传播行为类型,而不直接使用TransactionDefinition接口里定义的属性。
在TransactionDefinition接口中定义了Spring事务的一些属性,不仅包括事务传播特性类型,还包括了事务的隔离级别类型(事务的隔离级别后面文章会详细讲解),更多详细信息,大家可以打开源码自己翻译一下里面的注释。
REQUIRED(Spring默认的事务传播类型)
如果当前没有事务,则自己新建一个事务,如果当前存在事务,则加入这个事务
SUPPORTS
当前存在事务,则加入当前事务,如果当前没有事务,就以非事务方法执行
MANDATORY
当前存在事务,则加入当前事务,如果当前事务不存在,则抛出异常。
REQUIRES_NEW
创建一个新事务,如果存在当前事务,则挂起该事务。
NOT_SUPPORTED
始终以非事务方式执行,如果当前存在事务,则挂起当前事务
NEVER
不使用事务,如果当前事务存在,则抛出异常
NESTED
如果当前事务存在,则在嵌套事务中执行,否则REQUIRED的操作一样(开启一个事务)
这里需要注意两点:
和REQUIRES_NEW的区别
REQUIRES_NEW是新建一个事务并且新开启的这个事务与原有事务无关,而NESTED则是当前存在事务时(我们把当前事务称之为父事务)会开启一个嵌套事务(称之为一个子事务)。
在NESTED情况下父事务回滚时,子事务也会回滚,而在REQUIRES_NEW情况下,原有事务回滚,不会影响新开启的事务。
和REQUIRED的区别
REQUIRED情况下,调用方存在事务时,则被调用方和调用方使用同一事务,那么被调用方出现异常时,由于共用一个事务,所以无论调用方是否catch其异常,事务都会回滚
而在NESTED情况下,被调用方发生异常时,调用方可以catch其异常,这样只有子事务回滚,父事务不受影响
12、spring事务什么时候会失效?
spring事务的原理是AOP,进行了切面增强,那么失效的根本原因是这个AOP不起作用!常见情况如下几种
1、发生是调用,类里面使用this调用本类发方法(this通常省略),此时这个this对象不是代理类,而是UserService对象本身!
解决办法很简单,让那个this变成UserService的代理类即可!
2方法不是public修饰的
@Transactional 只能用于public 的方法否者事务不会生效,如果要用在非public 方法上,可以开启
AspectJ 代理模式
3、数据库不支持事务
InnoDB支持事务,MyISAM不支持,这一点是非常之重要。事务是一种高级的处理方式,如在一些列增删改中只要哪个出错还可以回滚还原,而MyISAM就不可以了。
链接: 了解数据库存储引擎.
4、没有被spring管理
链接: 了解spring事务管理.
5、异常被catch掉,事务不会回滚(或者抛出的异常没有被定义,默认为RuntimeExcelption)
13、什么是bean的自动装配,有哪些方式?
spring 配置文件中 <bean> 节点的 autowire 参数可以控制 bean 自动装配的方式
default - 默认的方式和 "no" 方式一样
no - 不自动装配,需要使用 <ref />节点或参数
byName - 根据名称进行装配
byType - 根据类型进行装配
constructor - 根据构造函数进行装配
开启自动装配,只需要在xml配置文件<bean>定义“autowire”属性
<bean id="cutomer" class="com.xxx.xxx.Customer" autowire="">
autowire属性有五种装配的方式:
no-缺省情况下,自动配置是通过“ref”属性手动设定
手动装配:以value或ref的方式明确指定属性值都是手动装配,需要通过“ref”属性来连接bean
byName:根据bean的属性名称进行自动装配
Customer的属性名称是person,Spring会将bean id为person的bean通过setter方法进行装配
<bean id="customer" class="com.xxx.xxx.Customer" autowire="byName"/>
<bean id="person" class="com.xxx.xxx.Person"/>
byType:根据bean的类型进行自动装配
Customer的属性名称是person,Spring会Person类型通过setter方法进行装配
<bean id="customer" class="com.xxx.xxx.Customer" autowire="byType"/>
<bean id="person" class="com.xxx.xxx.Person"/>
constructor:类似byType,不过是应用于构造器参数,如果一个bean与构造器参数的类型相同,则进行自动装配,否则导致异常
Customer的构造器参数person类型是Person,Spring会Person类型通过构造方法方法进行装配
<bean id="customer" class="com.xxx.xxx.Customer" autowire="constructor"/>
<bean id="person" class="com.xxx.xxx.Person"/>
autodetect:如果有默认的构造器,则通过constructor方式进行装配,否则使用byType方式进行自动装配