Spring一些知识点

东西还不少，暂时不看，大致知道原理，细节方面直说不会。

Spring两大核心之一IOC

降低代码的耦合度。

在一般的IOC场景中容器创建了所有的对象，并设置了必要的属性将他们联系在一起，等到需要使用的时候才把他们声明出来，使用注解就很方便了，容器会自动根据注解把对象组合起来。

IoC（Inverse of Control:控制反转）是一种设计思想 或者说是某种模式。这个设计思想就是 将原本在程序中手动创建对象的控制权，交由 Spring 框架来管理。 IoC 在其他语言中也有应用，并非 Spring 特有。IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个 Map（key，value）,Map 中存放的是各种对象。

IoC 最常见以及最合理的实现方式叫做依赖注入（Dependency Injection，简称 DI）。

依赖注入

在依赖注入中，您不必创建对象，但必须描述如何创建它们。

通常，依赖注入可以通过四种方式完成，即：

构造函数注入
setter 注入
接口注入
属性注入

在 Spring Framework 中，仅使用构造函数和 setter 注入。

属性注入

通过属性注入的方式非常常用，这个应该是大家比较熟悉的一种方式：

@Service
public class UserService {
    @Autowired
    private Wolf1Bean wolf1Bean;//通过属性注入
}

setter 方法注入

除了通过属性注入，通过 setter 方法也可以实现注入：

@Service
public class UserService {
    private Wolf3Bean wolf3Bean;
    
    @Autowired  //通过setter方法实现注入
    public void setWolf3Bean(Wolf3Bean wolf3Bean) {
        this.wolf3Bean = wolf3Bean;
    }
}

构造器注入

当两个类属于强关联时，我们也可以通过构造器的方式来实现注入：

@Service
public class UserService {
     private Wolf2Bean wolf2Bean;
    
     @Autowired //通过构造器注入
    public UserService(Wolf2Bean wolf2Bean) {
        this.wolf2Bean = wolf2Bean;
    }
}

接口注入

在上面的三种常规注入方式中，假如我们想要注入一个接口，而当前接口又有多个实现类，那么这时候就会报错，因为 Spring 无法知道到底应该注入哪一个实现类。比如我们上面的三个类全部实现同一个接口 IWolf，那么这时候直接使用常规的，不带任何注解元数据的注入方式来注入接口 IWolf。

@Autowired
private IWolf iWolf;

此时启动服务就会报错：这个就是说本来应该注入一个类，但是 Spring 找到了几个，所以没法确认到底应该用哪一个。这个问题如何解决呢？

通过 @Resource 注解动态获取

如果不想手动获取，我们也可以通过 @Resource 注解的形式动态指定 BeanName 来获取：

@Component
public class InterfaceInject {
    @Resource(name = "wolf1Bean")
    private IWolf iWolf;
}

如上所示则只会注入 BeanName 为 wolf1Bean 的实现类。

注入一个 Bean 可以通过 @Autowrire，也可以通过 @Resource 注解来注入，这两个注解有什么区别呢？

@Autowrite：通过类型去注入，可以用于构造器和参数注入。当我们注入接口时，其所有的实现类都属于同一个类型，所以就没办法知道选择哪一个实现类来注入。
@Resource：默认通过名字注入，不能用于构造器和参数注入。如果通过名字找不到唯一的 Bean，则会通过类型去查找。如下可以通过指定 name 或者 type 来确定唯一的实现：

Spring两大核心之二AOP

面对切面编程，这是一种编程模式，允许程序员通过自定义的横切点进行模块化，将那些影响多个类的行为封装到可重用的模块中。例子：比如日志输出，不使用AOP的话就需要把日志的输出语句放在所有类中，方法中，但是有了AOP就可以把日志输出语句封装一个可重用模块，在以声明的方式将他们放在类中，每次使用类就自动完成了日志输出。

实现 AOP 的技术，主要分为两大类：

静态代理 - 指使用 AOP 框架提供的命令进行编译，从而在编译阶段就可生成 AOP 代理类，因此也称为编译时增强；
- 编译时编织（特殊编译器实现）
- 类加载时编织（特殊的类加载器实现）。
动态代理 - 在运行时在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。
- JDK 动态代理：通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK 动态代理的核心是 InvocationHandler 接口和 Proxy 类。
- CGLIB动态代理：如果目标类没有实现接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。CGLIB （ Code Generation Library ），是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意， CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 final ，那么它是无法使用 CGLIB 做动态代理的。

BeanFactory和ApplicationContext的区别

接口 BeanFactory 和 ApplicationContext 都是用来从容器中获取 Spring beans 的，但是，他们二者有很大不同。

通常来说，Spring beans 就是被 Spring 容器所管理的 Java 对象。Spring 容器负责实例化，配置和装配 Spring beans。

通常情况，BeanFactory 的实现是使用懒加载的方式，这意味着 beans 只有在我们通过 getBean() 方法直接调用它们时才进行实例化实现 BeanFactory 最常用的 API 是 XMLBeanFactory。

public class HelloWorldApp {
    public static void main(String[] args) {
        XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("beans.xml"));
        HelloWorld obj = (HelloWorld) factory.getBean("helloWorld");
        obj.getMessage();
    }
}

ApplicationContext的优缺点：

优点：所有的Bean在启动的时候都进行了加载，系统运行的速度快；在系统启动的时候，可以发现系统中的配置问题。
缺点：把费时的操作放到系统启动中完成，所有的对象都可以预加载，缺点就是内存占用较大。

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
    HelloWorld obj = (HelloWorld) context.getBean("helloWorld");
    obj.getMessage();
}

spring bean的生命周期

Spring会根据beanDefinition来完成bean的创建，为什么不直接使用对象的class对象来创建bean呢？因为在class对象仅仅能描述一个对象的创建，它不足以用来描述一个Spring bean，而对于是否为懒加载、是否是首要的、初始化方法是哪个、销毁方法是哪个，这个Spring中特有的属性在class对象中并没有，所有Spring就定义了beanDefinition来完成bean的创建。

spring 支持几种 bean scope

Spring bean 支持 5 种 scope：

Singleton - 每个 Spring IoC 容器仅有一个单实例。
Prototype - 每次请求都会产生一个新的实例。
Request - 每一次 HTTP 请求都会产生一个新的实例，并且该 bean 仅在当前 HTTP 请求内有效。
Session - 每一次 HTTP 请求都会产生一个新的 bean，同时该 bean 仅在当前 HTTP session 内有效。
Global-session - 类似于标准的 HTTP Session 作用域，不过它仅仅在基于 portlet 的 web 应用中才有意义。Portlet 规范定义了全局 Session 的概念，它被所有构成某个 portlet web 应用的各种不同的 portlet 所共享。在 global session 作用域中定义的 bean 被限定于全局 portlet Session 的生命周期范围内。如果你在 web 中使用 global session 作用域来标识 bean，那么 web 会自动当成 session 类型来使用。

Spring如何解决循环依赖的问题

首先Spring尝试通过ApplicationContext.getBean()方法获取A对象的实例，由于Spring容器中还没有A对象实例，因而其会创建一个A对象。

然后发现其依赖了B对象，因而会尝试递归的通过ApplicationContext.getBean()方法获取B对象的实例。

但是Spring容器中此时也没有B对象的实例，因而其还是会先创建一个B对象的实例。

读者需要注意这个时间点，此时A对象和B对象都已经创建了，并且保存在Spring容器中了，只不过A对象的属性b和B对象的属性a都还没有设置进去。

在前面Spring创建B对象之后，Spring发现B对象依赖了属性A，因而还是会尝试递归的调用ApplicationContext.getBean()方法获取A对象的实例。

因为Spring中已经有一个A对象的实例，虽然只是半成品（其属性b还未初始化），但其也还是目标bean，因而会将该A对象的实例返回。

此时，B对象的属性a就设置进去了，然后还是ApplicationContext.getBean()方法递归的返回，也就是将B对象的实例返回，此时就会将该实例设置到A对象的属性b中。

这个时候，注意A对象的属性b和B对象的属性a都已经设置了目标对象的实例了。

读者朋友可能会比较疑惑的是，前面在为对象B设置属性a的时候，这个A类型属性还是个半成品。但是需要注意的是，这个A是一个引用，其本质上还是最开始就实例化的A对象。

而在上面这个递归过程的最后，Spring将获取到的B对象实例设置到了A对象的属性b中了。

这里的A对象其实和前面设置到实例B中的半成品A对象是同一个对象，其引用地址是同一个，这里为A对象的b属性设置了值，其实也就是为那个半成品的a属性设置了值。