Spring核心思想

Spring是一个库，它的功能是提供了一个软件框架，这个框架目的是使软件之间的逻辑更加清晰，配置更灵活，实现这个目的的手段使用AOP和IoC，而AOP和IoC是一种思想。

1、IoC(控制反转)
　　所谓的IOC称之为控制反转，简单来说就是将对象 的创建的权力及对象的生命周期的管理过程交由Spring框架来处理，从此在开发过程中不在需要关注对象的创建和生命周期的管理,而是在需要的时候由Spring框架提供，这个由Spring框架管理对象创建和生命周期的机制称之为控制反转。

2、DI(依赖注入)
　　在创建对象的过程中Spring可以依据配置对对象的属性进行设置，这个过程称之为依赖注入，也即DI

3.AOP（Aspect Oriented Programming，面向切面编程）

        AOP（Aspect Oriented Programming），即面向切面编程，可以说是OOP（Object Oriented Programming，面向对象编程）的补充和完善。OOP引入封装、继承、多态等概念来建立一种对象层次结构，用于模拟公共行为的一个集合。不过OOP允许开发者定义纵向的关系，但并不适合定义横向的关系，例如日志功能。日志代码往往横向地散布在所有对象层次中，而与它对应的对象的核心功能毫无关系对于其他类型的代码，如安全性、异常处理和透明的持续性也都是如此，这种散布在各处的无关的代码被称为横切（cross cutting），在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。

        AOP技术恰恰相反，它利用一种称为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。

        使用"横切"技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处基本相似，比如权限认证、日志、事物。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。        

Spring整体架构

Spring框架是一个分层架构，它包含一系列的功能要素，并被分为大概20个模块。

这些模块被总结为以下几个部分：

（1）Core Container

Core Container（核心容器）包含有Core、Beans、Context和Expression Language模块。

• Core模块主要包含Spring框架的核心工具类，Spring的其他组件都要使用这个包里的类，Core模块是其他组件的核心。

• Beans模块是所有应用都要用到的，它包含访问配置文件、创建和管理bean以及进行Inversion of Control/Dependency Injection（IOC / DI ）操作相关的所有类。

• Context模块构建于Core和Beans模块基础之上，提供了一种类似于JNDI注册器的框架式的对象访问方法，Context模块继承了Beans的特性，为Spring核心提供了大量扩展。Context模块同时也支持J2EE的一些特性，ApplicationContext是Context模块的关键。

• Expression Language 是一种强大的表达式语言，支持在运行时查询和操作对象。语言语法类似于Unified EL，但提供了额外的功能，特别是方法调用和基本的字符串模板功能。同时因为SpEL是以API接口的形式创建的，所以允许将其集成到其他应用程序和框架中。Spring框架的核心功能之一就是通过依赖注入的方式来管理Bean之间的依赖关系，而SpEl可以方便快捷的对ApplicationContext中的Bean进行属性的装配和提取。

（2）Data Access / Integration

Data Access/Integration层包含有JDBC、ORM、OXM、JMS和Transaction模块。

• JDBC模块提供了一个JDBC抽象层，它可以消除冗长的JDBC代码和解析数据库厂商特有的错误代码。这个模块包含了Spring对JDBC数据访问进行封装的所有类。

• ORM模块为流行的对象-关系映射API，如JPA、JDO、Hibernate、iBatis等，提供了一个交互层。利用ORM封装包，可以混合使用Spring提供的特性进行O/R映射。

• OXM模块提供了一个对Object/XML映射实现的抽象层，Object/XML映射实现包括JAXB、Castor、XMLBeans、JiBX和XStream。

• JMS（Java Messaging Service）模块主要包含了一些制造和消费消息的特性。

• Transaction模块支持编程和声明性的是管理，这些事物类必须实现特定的接口，并且对所有的POJO都适用。

（3）Web

Web上下文模块建立在应用程序上下文模块之上，为基于Web的应用程序提供了上下文。所以，Spring框架支持与Jakarta Struts的集成。Web模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。Web层包括了Web、Web-Servlet、Web-Struts和Web-Porlet模块。

• Web模块：提供了基础的面向Web的集成特性。例如，多文件上传、使用servlet listeners初始化IOC容器以及一个面向Web的应用上下文。它还包括Spring远程支持中Web的相关部分。

• Web-servlet模块web.servlet.jar：该模块包含Spring的model-view-controller（MVC）实现。Spring的MVC框架使得模型范围内的代码和web forms之间能够清楚地分离开来，并与Spring框架的其它特性集成在一起。

• Web-Struts模块：该模块提供了对Struts的支持，使得类在Spring应用中能够与一个典型的Struts Web层集成在一起。

• Web-Porlet模块：提供了用于Prolet环境和Web-Servlet模块的MVC实现。

（4）AOP

AOP模块提供了一个符合AOP联盟标准的面向切面编程的实现，它让你可以定义例如方法拦截器和切点，从而将逻辑代码分开，降低它们之间的耦合度。利用source-level的元数据功能，还可以将各种行为信息合并到你的代码中。

通过配置管理特性，Spring AOP模块直接将面向切面的编程功能集成到了Spring框架中，所以很容易地使用Spring框架管理的任何对象支持AOP。Spring AOP模块为基于Spring的应用程序中的对象提供了事物管理服务。通过使用Spring Aop,不用依赖EJB组件，就可以将声明性事务管理集成到应用程序中。

• Aspects模块提供了对AspectJ的集成支持。

• Instrumentation模块提供了class instrumentation支持和classloader实现，使得可以在特定的应用服务器上使用。

（5）Test

Test模块支持使用JUnit和TestNG对Spring组件进行测试。

容器的基本实现

 容器的实现类并不是唯一的，Spring 框架提供了多个容器的实现，这些容器分为两套体系：一套是早期的 BeanFactory 体系；还有一套是现在常用的 ApplicationContext，也可称为应用上下文，它继承了 BeanFactory，它除了有 BeanFactory 的功能外，还提供了其他服务，例如事务和 AOP 服务、国际化（il8n）的消息源以及应用程序事件处理等企业级的服务。

        说到这，就不得不说 Spring 的两种配置方式，在早期都是 XML 配置文件的方式，而现在使用的是注解配置的方式。BeanFactory 体系的容器一般用来处理 XML 配置文件的方式，而 ApplicationContext 体系则都可以处理。

BeanFactory

BeanFactory 是容器最基础的类，它定义了容器的基本功能规范：

public interface BeanFactory {


    // 对 FactoryBean 的转义定义，因为如果使用 bean 的名字检索 FactoryBean 得到的对象是工厂生成的对象，
    // 如果需要得到工厂本身，需要转义（FactoryBean 在后续会详细介绍）
    String FACTORY_BEAN_PREFIX = "&";
    
    // 根据 bean 的名字，获取在容器中 bean 实例
    Object getBean(String name) throws BeansException;
    
    //根据 bean 的名字和 Class 类型来得到 bean 实例，增加了类型安全验证机制。
    <T> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException;
    Object getBean(String name, Object... args) throws BeansException;
    <T> T getBean(Class<T> requiredType) throws BeansException;
    <T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
    
    // 提供对 bean 的检索，看看是否在容器有这个名字的 bean
    boolean containsBean(String name);
    
    // 根据 bean 名字，判断这个 bean 是不是单例
    boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
    
    // 根据 bean 名字，判断这个 bean 是不是原型
    boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
    
    // 根据 bean 名字，判断是否与指定的类型匹配
    boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
    boolean isTypeMatch(String name, @Nullable Class<?> typeToMatch) throws NoSuchBeanDefinitionException;
    
    // 得到 bean 实例的 Class 类型
    Class<?> getType(String name) throws NoSuchBeanDefinitionException;
    
    // 得到bean 的别名，如果根据别名检索，那么其原名也会被检索出来
    String[] getAliases(String name);
}

        在 BeanFactory 里只对容器的基本行为作了定义，其根本不关心你的 Bean 是如何定义怎样加载的。
        正如我们只关心工厂里得到什么的产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心。而要知道工厂是如何产生对象的，我们就需要看具体的容器了，也就是 BeanFactory 的子类。

BeanFactory 体系中常用的实现类有：

• ListableBeanFactory：提供容器中 bean 迭代的功能。如返回所有 Bean 的名字、容器中 Bean 的数量等。

• HierarchicalBeanFactory：提供父容器的访问功能，可通过 ConfigurableBeanFactory 的 setParentBeanFactory 方法设置父容器。

• AutowireCapableBeanFactory：为 Spring 容器之外的 Bean ，也就是未交由 Spring 管理的 Bean ，提供依赖注入的功能。

以上三个是 BeanFactory 的直系亲属，这个三个直系亲属下面又派生了两个复杂的容器：

• ConfigurableBeanFactory：其继承了 HierarchicalBeanFactory 和 SingletonBeanRegistry 这两个接口，其提供了很多方法，如：定义类加载器、类型转化、属性编辑器、注册依赖 Bean 、销毁 bean 等，且该接口被大多数的容器继承、实现。

• ConfigurableListableBeanFactory：这个接口继承了 ListableBeanFactory、 AutowireCapableBeanFactory、ConfigurableBeanFactory，自身主要提供用于分析和修改 bean 定义以及预先实例化单例 Bean 的方法。

最后是核心容器：

• DefaultListableBeanFactory：它实现了以上所有的接口，在 BeanFactory 体系中可以作为一个独立的容器使用。

BeanFactory 大致的继承关系如下：

        其实以前常用的容器是 XmlBeanFactory ，它是 DefaultListableBeanFactory 的实现类，现已被废除，原因还未找到，有知道的小伙伴，可在底下留言告知。

        但我们基本不单独使用 BeanFactory ，而是直接使用 ApplicationContext ，因为 ApplicationContext 包含了 BeanFactory。

ApplicationContext

        上面说过 ApplicationContext 是 BeanFactory 子类，它不仅包含 BeanFactory 所有功能，还对其进行了扩展，而我们喜欢将 ApplicationContext 称为应用上下文，因为容器只是它的基本功能。

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
    MessageSource, ApplicationEventPublisher, ResourcePatternResolver {


  // 返回此应用程序上下文的唯一ID
  @Nullable
  String getId();


  // 返回此上下文所属的应用程序名称
  String getApplicationName();


  // 返回应用上下文具像化的类名
  String getDisplayName();


  // 返回第一次加载此上下文时的时间戳
  long getStartupDate();


  // 获取父级应用上下文
  @Nullable
  ApplicationContext getParent();


  // 将 AutowireCapableBeanFactory 接口暴露给外部使用
  AutowireCapableBeanFactory getAutowireCapableBeanFactory() throws IllegalStateException;
}

ApplicationContext 自身提供的方法非常简单，但它继承了六个接口，来扩展自身功能：

• EnvironmentCapable：获取 Environment。

• ListableBeanFactory、HierarchicalBeanFactory：这是 BeanFactory 体系接口，分别提供 Bean 迭代和访问父容器的功能。

• MessageSource：支持国际化功能。

• ApplicationEventPublisher：应用事件发布器，封装事件发布功能的接口。

• ResourcePatternResolver：该接口继承至 ResourceLoader ，作用是加载多个 Resource。

ApplicationContext 同样提供了非常多的实现类，其又可细分为两大类， ConfigurableApplicationContext 和 WebApplicationContext。

ConfigurableApplicationContext

该接口是比较重要的一个接口，几乎所有的应用上下文都实现了该接口。该接口在ApplicationContext的基础上提供了配置应用上下文的能力，此外提供了生命周期的控制能力。

public interface ConfigurableApplicationContext extends ApplicationContext, Lifecycle, Closeable {


  // 应用上下文配置时，这些符号用于分割多个配置路径
  String CONFIG_LOCATION_DELIMITERS = ",; \t\n";


  // BeanFactory中，ConversionService类所对应的bean的名字。如果没有此类的实例的话吗，则使用默认的转换规则
  String CONVERSION_SERVICE_BEAN_NAME = "conversionService";


  //LoadTimeWaver类所对应的Bean在容器中的名字。如果提供了该实例，上下文会使用临时的 ClassLoader ，这样，LoadTimeWaver就可以使用bean确切的类型了 
  String LOAD_TIME_WEAVER_BEAN_NAME = "loadTimeWeaver";


  // Environment 类在容器中实例的名字
  String ENVIRONMENT_BEAN_NAME = "environment";


  // System 系统变量在容器中对应的Bean的名字
  String SYSTEM_PROPERTIES_BEAN_NAME = "systemProperties";


  // System 环境变量在容器中对应的Bean的名字
  String SYSTEM_ENVIRONMENT_BEAN_NAME = "systemEnvironment";


    // 设置容器的唯一ID
  void setId(String id);


  // 设置此容器的父容器
  void setParent(@Nullable ApplicationContext parent);


  // 设置容器的 Environment 变量
  void setEnvironment(ConfigurableEnvironment environment);


  // 以 ConfigurableEnvironment 的形式返回此容器的环境变量。以使用户更好的进行配置
  @Override
  ConfigurableEnvironment getEnvironment();


  // 此方法一般在读取应用上下文配置的时候调用，用以向此容器中增加BeanFactoryPostProcessor。增加的Processor会在容器refresh的时候使用。
  void addBeanFactoryPostProcessor(BeanFactoryPostProcessor postProcessor);


  // 向容器增加一个 ApplicationListener，增加的 Listener 用于发布上下文事件，如 refresh 和 shutdown 等
  void addApplicationListener(ApplicationListener<?> listener);


  // 向容器中注入给定的 Protocol resolver
  void addProtocolResolver(ProtocolResolver resolver);


  // 这是初始化方法，因此如果调用此方法失败的情况下，要将其已经创建的 Bean 销毁。
    // 换句话说，调用此方法以后，要么所有的Bean都实例化好了，要么就一个都没有实例化
  void refresh() throws BeansException, IllegalStateException;


  // 向JVM注册一个回调函数，用以在JVM关闭时，销毁此应用上下文
  void registerShutdownHook();


  // 关闭此应用上下文，释放其所占有的所有资源和锁。并销毁其所有创建好的 singleton Beans
  @Override
  void close();


  // 检测此 FactoryBean 是否被启动过
  boolean isActive();


  // 返回此应用上下文的容器。
  // 千万不要使用此方法来对 BeanFactory 生成的 Bean 做后置处理，因为单例 Bean 在此之前已经生成。
    // 这种情况下应该使用 BeanFactoryPostProcessor 来在 Bean 生成之前对其进行处理
  ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;
}

该接口下又有几个重要的实现类：

• AbstractApplicationContext：这是个抽象类，仅实现了公共的上下文特性。这个抽象类使用了模板方法设计模式，需要具体的实现类去实现这些抽象的方法。

• GenericApplicationContext：该类继承自 AbstractApplicationContext，是为通用目的设计的，它能加载各种配置文件，例如 xml，properties 等等。它的内部持有一个 DefaultListableBeanFactory 的实例，实现了 BeanDefinitionRegistry 接口，以便允许向其应用任何 bean 的定义的读取器。

• AnnotationConfigApplicationContext：该类继承自 GenericApplicationContext ，提供了注解配置（例如：@Configuration、@Component等）和类路径扫描（scan方法）的支持。

 WebApplicationContext

        该接口是专门为 Web 应用准备的，其允许从相对于 Web 根目录的路径中装载配置文件完成初始化。

public interface WebApplicationContext extends ApplicationContext {


  // 整个 Web 应用上下文是作为属性放置在 ServletContext 中的，该常量就是应用上下文在 ServletContext 属性列表中的 key
  String ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE = WebApplicationContext.class.getName() + ".ROOT";


  // 定义了三个作用域的名称
  String SCOPE_REQUEST = "request";
  String SCOPE_SESSION = "session";
  String SCOPE_APPLICATION = "application";


  // 在工厂中的 bean 名称
  String SERVLET_CONTEXT_BEAN_NAME = "servletContext";


  // ServletContext 初始化参数名称
  String CONTEXT_PARAMETERS_BEAN_NAME = "contextParameters";


  // 在工厂中 ServletContext 属性值环境bean的名称
  String CONTEXT_ATTRIBUTES_BEAN_NAME = "contextAttributes";


  // 用来获取 ServletContext 对象
  @Nullable
  ServletContext getServletContext();
}

该接口的核心实现类有：

• ConfigurableWebApplicationContext：该接口同时继承了 WebApplicationContext 和 ConfigurableApplicationContext，提供了 Web 应用上下文的可配置的能力。

• GenericWebApplicationContext：该类继承自 GenericApplicationContext，实现了 ConfigurableWebApplicationContext。

• XmlWebApplicationContext：该上下文是使用 Xml 配置文件的方式，不过是在 Web 环境中使用的。

• AnnotationConfigServletWebServerApplicationContext：该类是被 SpringBoot 扩展而来的，SpringBoot 使用的就是该上下文。

差异对比

从上面可以看出 BeanFactory 是 Sping 框架的基础接口，一般是面向 Spring 本身；而 ApplicationContext 是以 BeanFactory 为基础进行综合能力扩展，用于满足大型业务应用的创建， ApplicationContext 一般面向使用 Sping 框架的开发者。几乎所有的应用场合我们都是直接使用 ApplicationContet 而非底层的 BeanFactory。

下表列出了BeanFactory 和 ApplicationContext 接口和实现所提供的功能：

两者还有一个区别是：

• ApplicationContext 在容器启动时，一次性创建了所有的 Bean。

• BeanFactory 在容器启动时，并未创建 Bean，直到第一次访问某个 Bean 时才创建目标 Bean。