Spring生命周期和作用域：
（1）生命周期
Spring上下文中的Bean也类似，如下
a）实例化一个Bean－－也就是我们常说的new；
b）按照Spring上下文对实例化的Bean进行配置－－也就是IOC注入；
c）如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值
d）如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；
e）如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）；
f）如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；
g）如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。
h）如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；
注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，这里我们不做赘述。
i）当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；
j）最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。
以上10步骤可以作为面试或者笔试的模板，另外我们这里描述的是应用Spring上下文Bean的生命周期，如果应用Spring的工厂也就是BeanFactory的话去掉第5步就Ok了。
（2）作用域
五种作用域中，request、session和global session三种作用域仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架），只能用在基于web的SpringApplicationContext环境。
(1)当一个bean的作用域为Singleton，那么Spring IoC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。Singleton是单例类型，就是在创建起容器时就同时自动创建了一个bean的对象，不管你是否使用，他都存在了，每次获取到的对象都是同一个对象。注意，Singleton作用域是Spring中的缺省作用域。要在XML中将bean定义成singleton，可以这样配置：
<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" scope="singleton">
(2)当一个bean的作用域为Prototype，表示一个bean定义对应多个对象实例。Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。Prototype是原型类型，它在我们创建容器的时候并没有实例化，而是当我们获取bean的时候才会去创建一个对象，而且我们每次获取到的对象都不是同一个对象。根据经验，对有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。在XML中将bean定义成prototype，可以这样配置：
<bean id="account" class="com.foo.DefaultAccount" scope="prototype"/>
或者
<bean id="account" class="com.foo.DefaultAccount" singleton="false"/>
(3)当一个bean的作用域为Request，表示在一次HTTP请求中，一个bean定义对应一个实例；即每个HTTP请求都会有各自的bean实例，它们依据某个bean定义创建而成。该作用域仅在基于web的Spring
ApplicationContext情形下有效。考虑下面bean定义：
<bean id="loginAction" class=cn.csdn.LoginAction" scope="request"/>
针对每次HTTP请求，Spring容器会根据loginAction bean的定义创建一个全新的LoginAction bean实例，且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。
(4)当一个bean的作用域为Session，表示在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样，可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。
(5)当一个bean的作用域为Global Session，表示在一个全局的HTTP Session中，一个bean定义对应一个实例。典型情况下，仅在使用portlet context的时候有效。该作用域仅在基于web的SpringApplicationContext情形下有效。考虑下面bean定义：
<bean id="user" class="com.foo.Preferences "scope="globalSession"/>
global session作用域类似于标准的HTTP Session作用域，不过仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。
Spring IOC/DI:
Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转？
● 谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
● 为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
传统程序设计如下图，都是主动去创建相关对象然后再组合起来：
当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如下图所示：
IoC能做什么
IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。
IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。
IoC和DI
DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：
● 谁依赖于谁：当然是应用程序依赖于IoC容器；
● 为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
● 谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
● 注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
在spring ioc中有三种依赖注入，分别是：
a、接口注入；
b、setter方法注入；
c、构造方法注入；
接口注入
public class ClassA {
private InterfaceB clzB;
public void doSomething(){
Ojbect obj =Class.forName(Config.BImplementation).newInstance();
clzB =(InterfaceB)obj;
clzB.doIt();
}
……
}
解释一下上述的代码部分，ClassA依赖于InterfaceB的实现，我们如何获得InterfaceB的实现实例呢？传统的方法是在代码中创建 InterfaceB实现类的实例，并将赋予clzB.这样一来，ClassA在编译期即依赖于InterfaceB的实现。为了将调用者与实现者在编译期分离，于是有了上面的代码。我们根据预先在配置文件中设定的实现类的类名(Config.BImplementation),动态加载实现类，并通过InterfaceB强制转型后为ClassA所用，这就是接口注入的一个最原始的雏形。
setter方法注入
setter注入模式在实际开发中有非常广泛的应用，setter方法更加直观，我们来看一下spring的配置文件：
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-4.1.xsd
http://www.springframework.org/schema/aophttp://www.springframework.org/schema/aop/spring-aop-4.1.xsd
http://www.springframework.org/schema/txhttp://www.springframework.org/schema/tx/spring-tx-4.1.xsd">
接着我们来看一下，setter表示依赖关系的写法：
public class UserManagerImpl implements UserManager{
private UserDaouserDao;
//使用设值方式赋值
public voidsetUserDao(UserDao userDao) {
this.userDao =userDao;
}
@Override
public voidaddUser(String userName, String password) {
userDao.addUser(userName, password);
}
}
构造器注入
构造器注入，即通过构造函数完成依赖关系的设定。我们看一下spring的配置文件：
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-4.1.xsd
http://www.springframework.org/schema/aophttp://www.springframework.org/schema/aop/spring-aop-4.1.xsd
http://www.springframework.org/schema/txhttp://www.springframework.org/schema/tx/spring-tx-4.1.xsd">
我们再来看一下，构造器表示依赖关系的写法，代码如下所示：
public class UserManagerImpl implements UserManager{
private UserDaouserDao;
//使用构造方式赋值
publicUserManagerImpl(UserDao userDao) {
this.userDao =userDao;
}
@Override
public voidaddUser(String userName, String password) {
userDao.addUser(userName, password);
}
}
接口注入 vs setter注入 vs 构造器注入
接口注入：
接口注入模式因为具备侵入性，它要求组件必须与特定的接口相关联，因此并不被看好，实际使用有限。
Setter 注入：
对于习惯了传统javabean开发的程序员，通过setter方法设定依赖关系更加直观。如果依赖关系较为复杂，那么构造子注入模式的构造函数也会相当庞大，而此时设值注入模式则更为简洁。如果用到了第三方类库，可能要求我们的组件提供一个默认的构造函数，此时构造子注入模式也不适用。
构造器注入：
在构造期间完成一个完整的、合法的对象。所有依赖关系在构造函数中集中呈现。依赖关系在构造时由容器一次性设定，组件被创建之后一直处于相对“不变”的稳定状态。只有组件的创建者关心其内部依赖关系，对调用者而言，该依赖关系处于“黑盒”之中。
Spring AOP：
什么是AOP呢？AOP（面向切面编程，Aspect-Oriented-Programming），可以说是OOP（面向对象编程，Object-Oriented-Programing）的完善和补充。OOP允许定义从上到下的关系，但并不适合定义从左到右的关系。比如日志功能。日志功能的代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。这种散布在各处的无关的代码被称之为横切（cross-cutting）代码，在面向对象的设计中，这种设计导致了大量代码的重复，出现冗余，提高了维护成本，而不利于各个模块的重用。
而AOP是利用一种称之为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块中，并且将其命名为"Aspect"，即切面。这所谓的"切面"，简而言之，就是把那些与业务无关的，却为业务模块所共同公共调用的逻辑或者责任封装起来，进而便于减少系统的重复代码量，并且能够降低模块间的耦合度，并有利于未来的可操作性和可维护性。
使用“横切”技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理。Aop 的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。
AOP的一些概念
描述AOP常用的一些术语有通知(Adivce)、切点（Pointcut）、连接点（Join point）、切面（Aspect）、引入（Introduction）、织入（Weaving）
通知分为五中类型：
● Before
在方法被调用之前调用
● After
在方法完成后调用通知，无论方法是否执行成功
● After-returning
在方法成功执行之后调用通知
● After-throwing
在方法抛出异常后调用通知
● Around
通知了好、包含了被通知的方法，在被通知的方法调用之前后调用之后执行自定义的行为
切点：对连接点进行拦截的定义
连接点：被拦截到的点，因为Spring只支持方法类型的连接点，所以在Spring中连接点指的就是被拦截到的方法，实际上连接点还可以是字段或者构造器
切面：类是对物体特征的抽象，切面就是对横切关注点的抽象。切面是切点和通知的结合。通知和切点共同定义了关于切面的全部内容，它是什么时候，在何时和何处完成功能。
引入：在不修改代码的前提下，引入可以在运行期为类动态地添加一些方法或字段。
织入：将切面应用到目标对象并导致代理对象创建的过程。
Spring实现方式
Spring AOP是利用代理模式，在运行时生成一个目标对象的代理，并且使用代理代替目标对象，整个过程对使用者透明，使用者无法像使用目标对象一样使用代理对象，代理对象类型是目标对象所属类的子类或者接口实现，这个子类也是在运行时动态生成，这个生成子类的过程使用操作字节码技术，Spring框架中使用两种字节码技术：JDK动态代理和CGLIB，当目标类实现了接口时使用JDK动态代理，否则使用CGLIB代理。
JDK动态代理主要涉及到java.lang.reflect包中的两个类：Proxy和InvocationHandler。InvocationHandler是一个接口，通过实现该接口定义横切逻辑，并通过反射机制调用目标类的代码，动态将横切逻辑和业务逻辑编制在一起。Proxy利用InvocationHandler动态创建一个符合某一接口的实例，生成目标类的代理对象。
CGLib全称为Code Generation Library，是一个强大的高性能，高质量的代码生成类库，可以在运行期扩展Java类与实现Java接口，CGLib封装了asm，可以再运行期动态生成新的class。和JDK动态代理相比较：JDK创建代理有一个限制，就是只能为接口创建代理实例，而对于没有通过接口定义业务方法的类，则可以通过CGLib创建动态代理。
AOP的实现包含下面几个步骤：
● 根据配置或注解解析切面。
● 生成AOP代理对象，给目标对象生成一个代理类以及代理类实例，根据解析出的切面，生成通知链设置到代理对象，在代理的回调中会执行通知链。
● 把AOP代理对象注册到容器中代替目标对象，当使用者向容器请求目标bean时，容器会返回代理对象。
