Spring原理剖析

• Spring模块
• Spring DAO
• Spring事务
• • 概述
  • • 事务首先是一系列操作组成的工作单元，该工作单元内的操作是不可分割的，即要么所有操作都做，要么所有操作都不做
    • ACID
    • • 原子性（Atomicity）
      • • 即事务是不可分割的最小工作单元，事务内的操作要么全做，要么全不做
      • 一致性（Consistency）
      • • 在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是处于正确的状态，即数据完整性约束没有被破坏
        • 如银行转帐，A转帐给B，必须保证A的钱一定转给B，一定不会出现A的钱转了但B没收到，否则数据库的数据就处于不一致（不正确）的状态
      • 隔离性（Isolation）
      • • 并发事务执行之间无影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性
      • 持久性（Durability）
      • • 事务一旦执行成功，它对数据库的数据的改变必须是永久的，不会因比如遇到系统故障或断电造成数据不一致或丢失
    • 常见问题
    • • 丢失更新、
      • • 两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的
      • 脏读
      • • 一个事务看到了另一个事务未提交的更新数据
      • 不可重复读、
      • • 在同一事务中，多次读取同一数据却返回不同的结果；也就是有其他事务更改了这些数据
        • 不可重复读的重点是修改
      • 幻读
      • • 一个事务在执行过程中读取到了另一个事务已提交的插入数据；即在第一个事务开始时读取到一批数据，但此后另一个事务又插入了新数据并提交，此时第一个事务又读取这批数据但发现多了一条，即好像发生幻觉一样
        • 幻读的重点在于新增或者删除
    • 隔离级别
    • • 未提交读（Read Uncommitted）
      • • 最低隔离级别，一个事务能读取到别的事务未提交的更新数据，很不安全，可能出现丢失更新、脏读、不可重复读、幻读
      • 提交读（Read Committed）
      • • 一个事务能读取到别的事务提交的更新数据，不能看到未提交的更新数据，不可能可能出现丢失更新、脏读，但可能出现不可重复读、幻读
      • 可重复读（Repeatable Read）
      • • 保证同一事务中先后执行的多次查询将返回同一结果，不受其他事务影响，可能出现丢失更新、脏读、不可重复读，但可能出现幻读
      • 序列化（Serializable）
      • • 最高隔离级别，不允许事务并发执行，而必须串行化执行，最安全，不可能出现更新、脏读、不可重复读、幻读
    • 隔离级别越高，数据库事务并发执行性能越差，能处理的操作越少。因此在实际项目开发中为了考虑并发性能一般使用提交读隔离级别，它能避免丢失更新和脏读，尽管不可重复读和幻读不能避免，但可以在可能出现的场合使用悲观锁或乐观锁来解决这些问题
    • • 从数据库系统的角度来看，锁分为以下三种类型
      • • 独占锁（Exclusive Lock）
        • • 独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放
        • 共享锁（Shared Lock）
        • • 共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放
        • 更新锁（Update Lock）
        • • 更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定
      • 从程序员的角度看，锁分为以下两种类型
      • • 悲观锁（Pessimistic Lock）
        • • 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
        • 乐观锁（Optimistic Lock）
        • • 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受
          • 而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如 果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据
    • 数据库事务类型
    • • 本地事务
      • • 就是普通事务，能保证单台数据库上的操作的ACID，被限定在一台数据库上
      • 分布式事务
      • • 涉及两个或多个数据库源的事务，即跨越多台同类或异类数据库的事务（由每台数据库的本地事务组成的），分布式事务旨在保证这些本地事务的所有操作的ACID，使事务可以跨越多台数据库
    • Java事务类型
    • • JDBC事务：就是数据库事务类型中的本地事务，通过Connection对象的控制来管理事务
      • JTA事务：JTA指Java事务API(Java Transaction API)，是Java EE数据库事务规范， JTA只提供了事务管理接口，由应用程序服务器厂商（如WebSphere Application Server）提供实现，JTA事务比JDBC更强大，支持分布式事务
    • Java EE事务类型
    • • 本地事务：使用JDBC编程实现事务
      • 全局事务：由应用程序服务器提供，使用JTA事务
    • 编程实现
    • • 声明式事务： 通过注解或XML配置文件指定事务信息
      • 编程式事务：通过编写代码实现事务
  • Spring事务使用
  • • 说明
    • • 结构
      • • DataSource
        • • JdbcDataSource
          • SessionFactory
          • EntityManager
        • TransactionManager
        • • DataSourceTransactionManager
          • HibernateTransactionManager
          • JpaTransactionManager
        • 代理机制
        • • Bean和代理
          • • 每个Bean有一个代理
            • 所有Bean共享一个代理基类
          • 使用拦截器
          • 使用TX标签配置的拦截器
          • 全注解配置
      • 无论哪种配置方式，一般变化的只是代理机制这部分
    • 5种实现方式
    • • 每个Bean都有一个代理
      • • 每个Bean用TransactionProxyFactoryBean代理
      • 所有Bean共享一个代理基类
      • • 所有Bean都集成TransactionProxyFactoryBean
      • 使用拦截器
      • • 拦截器：TransactionInterceptor
        • 根据beanName匹配后进行自动代理: BeanNameAutoProxyCreator
      • 使用tx标签配置的拦截器
      • • <tx:advice/>
        • <aop:config/>
      • 全注解
      • • Transactional
• Spring扩展
• • BeanPostProcessor
  • • BeanPostProcessor是Spring容器的一个扩展点，可以进行自定义的实例化、初始化、依赖装配、依赖检查等流程，即可以覆盖默认的实例化，也可以增强初始化、依赖注入、依赖检查等流程
    • BeanFactory <- AbstractBeanFactory <- AbstractAutowireCapableBeanFactory <- DefaultListableBeanFactory：AbstractAutowireCapableBeanFactory.createBean()负责Bean的初始化到消亡周期
    • • resolveBeanClass(mbd, beanName); 解析Bean class，若class配置错误将抛出CannotLoadBeanClassException
      • mbd.prepareMethodOverrides(); 准备和验证配置的方法注入，若验证失败抛出BeanDefinitionValidationException
      • Object bean = resolveBeforeInstantiation(beanName, mbd)
      • • 执行InstantiationAwareBeanPostProcessor的实例化的预处理回调方法postProcessBeforeInstantiation（自定义的实例化，如创建代理）
        • 执行InstantiationAwareBeanPostProcessor的实例化的后处理回调方法postProcessAfterInitialization（如依赖注入），如果3.1处返回的Bean不为null才执行
      • 如果3处的扩展点返回的bean不为空，直接返回该bean，后续流程不需要执行
      • Object beanInstance = doCreateBean(beanName, mbd, args); 执行spring的创建bean实例的流程
      • createBeanInstance(beanName, mbd, args); 实例化Bean
      • • instantiateUsingFactoryMethod 工厂方法实例化
        • 构造器实例化
        • 如果之前已经解析过构造器
        • • autowireConstructor：有参调用autowireConstructor实例化
          • instantiateBean：无参调用instantiateBean实例化
        • 如果之前没有解析过构造器
        • • 通过SmartInstantiationAwareBeanPostProcessor 的determineCandidateConstructors 回调方法解析构造器，第二个BeanPostProcessor扩展点，返回第一个解析成功（返回值不为null）的构造器组
          • autowireConstructor：如果（6.2.2.1返回的不为null，且是有参构造器，调用autowireConstructor实例化
          • instantiateBean： 否则调用无参构造器实例化
      • applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName)：执行Bean定义的合并
      • • 执行MergedBeanDefinitionPostProcessor的postProcessMergedBeanDefinition回调方法，进行bean定义的合并
      • addSingletonFactory(beanName, new ObjectFactory())
      • • SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference，当存在循环依赖时，通过该回调方法获取及早暴露的Bean实例
      • populateBean(beanName, mbd, instanceWrapper);装配Bean依赖
      • • InstantiationAwareBeanPostProcessor的postProcessAfterInstantiation；第五个BeanPostProcessor扩展点，在实例化Bean之后，所有其他装配逻辑之前执行，如果false将阻止其他的InstantiationAwareBeanPostProcessor的postProcessAfterInstantiation的执行和从（9.2到（9.5的执行，通常返回true
        • autowireByName、autowireByType：根据名字和类型进行自动装配
        • InstantiationAwareBeanPostProcessor的postProcessPropertyValues，完成其他定制的一些依赖注入，如
        • • AutowiredAnnotationBeanPostProcessor执行@Autowired注解注入
          • CommonAnnotationBeanPostProcessor执行@Resource等注解的注入
          • PersistenceAnnotationBeanPostProcessor执行@ PersistenceContext等JPA注解的注入
          • RequiredAnnotationBeanPostProcessor执行@Required注解的检查等等
        • checkDependencies：依赖检查
        • applyPropertyValues：应用明确的setter属性注入
      • initializeBean(beanName, exposedObject, mbd); 执行初始化Bean流程
      • • invokeAwareMethods（BeanNameAware、BeanClassLoaderAware、BeanFactoryAware）：调用一些Aware标识接口注入如BeanName、BeanFactory
        • BeanPostProcessor的postProcessBeforeInitialization：在调用初始化之前完成一些定制的初始化任务，如：
        • • BeanValidationPostProcessor完成JSR-303 @Valid注解Bean验证
          • InitDestroyAnnotationBeanPostProcessor完成@PostConstruct注解的初始化方法调用
          • ApplicationContextAwareProcessor完成一些Aware接口的注入（如EnvironmentAware、ResourceLoaderAware、ApplicationContextAware），其返回值将替代原始的Bean对象
        • invokeInitMethods ： 调用初始化方法
        • • InitializingBean的afterPropertiesSet ：调用InitializingBean的afterPropertiesSet回调方法
          • 通过xml指定的自定义init-method ：调用通过xml配置的自定义init-method
          • BeanPostProcessor的postProcessAfterInitialization
          • • AspectJAwareAdvisorAutoProxyCreator（完成xml风格的AOP配置(<aop:config>)的目标对象包装到AOP代理对象）
            • AnnotationAwareAspectJAutoProxyCreator（完成@Aspectj注解风格（<aop:aspectj-autoproxy> @Aspect）的AOP配置的目标对象包装到AOP代理对象），其返回值将替代原始的Bean对象
      • registerDisposableBeanIfNecessary(beanName, bean, mbd) ： 注册Bean的销毁方法（只有非原型Bean可注册）
      • • 单例Bean的销毁流程
        • • DestructionAwareBeanPostProcessor的postProcessBeforeDestruction ： 如InitDestroyAnnotationBeanPostProcessor完成@PreDestroy注解的销毁方法注册和调用
          • DisposableBean的destroy：注册/调用DisposableBean的destroy销毁方法
          • 通过xml指定的自定义destroy-method ： 注册/调用通过XML指定的destroy-method销毁方法
          • Scope的registerDestructionCallback：注册自定义的Scope的销毁回调方法，如RequestScope、SessionScope等
    • Spring内置的BeanPostProcessor
    • • ApplicationContextAwareProcessor
      • • 容器启动时会自动注册

        • 注入那些实现ApplicationContextAware、MessageSourceAware、ResourceLoaderAware、EnvironmentAware、

          EmbeddedValueResolverAware、ApplicationEventPublisherAware标识接口的Bean需要的相应实例
        • 在postProcessBeforeInitialization回调方法中进行实施
      • CommonAnnotationBeanPostProcessor
      • • CommonAnnotationBeanPostProcessor继承InitDestroyAnnotationBeanPostProcessor，当在配置文件有<context:annotation-config>或<context:component-scan>会自动注册
        • 提供对JSR-250规范注解的支持@javax.annotation.Resource、@javax.annotation.PostConstruct和@javax.annotation.PreDestroy等的支持、
        • 通过@Resource注解进行依赖注入
        • • postProcessPropertyValues：通过此回调进行@Resource注解的依赖注入
        • 用于执行@PostConstruct 和@PreDestroy 注解的初始化和销毁方法的扩展点
        • • postProcessBeforeInitialization()将会调用bean的@PostConstruct方法
          • postProcessBeforeDestruction()将会调用单例 Bean的@PreDestroy方法（此回调方法会在容器销毁时调用）
      • AutowiredAnnotationBeanPostProcessor
      • • 当在配置文件有<context:annotation-config>或<context:component-scan>会自动注册
        • 提供对JSR-330规范注解的支持和Spring自带注解的支持
        • Spring自带注解的依赖注入支持，@Autowired和@Value
        • • determineCandidateConstructors ：决定候选构造器
          • postProcessPropertyValues ：进行依赖注入
        • 对JSR-330规范注解的依赖注入支持，@Inject
      • RequiredAnnotationBeanPostProcessor
      • • 当在配置文件有<context:annotation-config>或<context:component-scan>会自动注册
        • 提供对@Required注解的方法进行依赖检查支持
        • • postProcessPropertyValues：如果检测到没有进行依赖注入时抛出BeanInitializationException异常
      • PersistenceAnnotationBeanPostProcessor
      • • 当在配置文件有<context:annotation-config>或<context:component-scan>会自动注册
        • 通过对JPA @javax.persistence.PersistenceUnit和@ javax.persistence.PersistenceContext注解进行依赖注入的支持
        • • postProcessPropertyValues ： 根据@PersistenceUnit/@PersistenceContext进行EntityManagerFactory和EntityManager的支持
      • AbstractAutoProxyCreator
      • • AspectJAwareAdvisorAutoProxyCreator和AnnotationAwareAspectJAutoProxyCreator都是继承AbstractAutoProxyCreator
        • AspectJAwareAdvisorAutoProxyCreator提供对（<aop:config>）声明式AOP的支持、
        • AnnotationAwareAspectJAutoProxyCreator提供对（<aop:aspectj-autoproxy>）注解式（@AspectJ）AOP的支持
        • 当使用<aop:config>配置时自动注册AspectJAwareAdvisorAutoProxyCreator
        • 使用<aop:aspectj-autoproxy>时会自动注册AnnotationAwareAspectJAutoProxyCreator
        • predictBeanType：预测Bean的类型，如果目标对象被AOP代理对象包装，此处将返回AOP代理对象的类型
        • postProcessBeforeInstantiation：配置TargetSourceCreator进行自定义TargetSource创建时，会创建代理对象并中断默认Spring创建流程
        • getEarlyBeanReference和postProcessAfterInitialization是二者选一的，而且单例Bean目标对象只能被增强一次，而原型Bean目标对象可能被包装多次
      • BeanValidationPostProcessor
      • • 默认不自动注册，Spring3.0开始支持
        • 提供对JSR-303验证规范支持
        • 根据afterInitialization是false/true决定调用postProcessBeforeInitialization或postProcessAfterInitialization来通过JSR-303规范验证Bean，默认false
    • BeanPostProcessor如何注册
    • • 如ApplicationContextAwareProcessor会在ApplicationContext容器启动时自动注册，而CommonAnnotationBeanPostProcessor和AutowiredAnnotationBeanPostProcessor会在当你使用<context:annotation-config>或<context:component-scan>配置时自动注册
      • 只要将BeanPostProcessor注册到容器中，Spring会在启动时自动获取并注册
    • BeanPostProcessor的执行顺序
    • • 如果使用BeanFactory实现，非ApplicationContext实现，BeanPostProcessor执行顺序就是添加顺序
      • 如果使用的是AbstractApplicationContext（实现了ApplicationContext）的实现，则通过如下规则指定顺序
      • • PriorityOrdered（继承了Ordered），实现了该接口的BeanPostProcessor会在第一个顺序注册，标识高优先级顺序，即比实现Ordered的具有更高的优先级
        • Ordered，实现了该接口的BeanPostProcessor会第二个顺序注册
  • Spring自定义功能标签
  • • XML通常通过DTD、XSD定义，但DTD的表达能力较弱，XSD定义则能力比较强，能够定义类型，出现次数等。自定义标签需要XSD支持，在实现时使用Namespace扩展来支持自定义标签
    • 工作过程
    • • Spring通过XML解析程序将其解析为DOM树，通过NamespaceHandler指定对应的Namespace的BeanDefinitionParser将其转换成BeanDefinition
      • 再通过Spring自身的功能对BeanDefinition实例化对象
    • 制作定义标签
    • • 编写XSD文件
      • META-INF/spring.schemas ：配置XSD文件
      • • 在解析XML文件时将XSD重定向到本地文件，避免在解析XML文件时需要上网下载XSD文件。通过现实org.xml.sax.EntityResolver接口来实现该功能
      • META-INF/spring.handlers
      • • 指定NamespaceHandler(实现org.springframework.beans.factory.xml.NamespaceHandler)接口，或使用org.springframework.beans.factory.xml.NamespaceHandlerSupport的子类
        • NamespaceHandler实现中注册标签和解析器
      • 实现配置 BeanDefinitionParser 
      • • 解析XML，实例构造想要的Bean为BeanDefinition对象
      • 配置自定义标签并获取对应的Bean
  • Spring自定义注解
  • • 使用Spring扩展机制
  • Spring PropertyPlaceholderConfigurer配置扩展
  • • 通过扩展PropertyPlaceholderConfigurer类自定义Spring取配置值的行为
    • 如通过扩展PropertyPlaceholderConfigurer，内部封装调用ZooKeeper动态配置获取，从而把ZooKeeper的Name Service集成到现有的Spring容器中
• Spring设计模式
• Subject（被观察者）：
• 设计模式区分
• • Façade模式、Adapter模式、Bridge模式与Decorator模式区别
  • • Façade模式注重简化接口
    • Adapter模式注重转换接口
    • Bridge模式注重分离接口（抽象）与其实现
    • Decorator模式注重稳定接口的前提下为对象扩展功能

转载自：http://blog.csdn.net/zhiguozhu/article/details/50517579