Analysis of Spring Principle

• Spring modules
• Spring DAO
• Spring Transactions
• • Overview
  • • A transaction is first of all a unit of work composed of a series of operations . The operations within the unit of work are inseparable, that is, either all operations are performed, or all operations are not performed.
    • ACID
    • • Atomicity
      • • That is, a transaction is an indivisible smallest unit of work , and the operations within a transaction are either done or not done at all .
      • Consistency
      • • The data in the database is in the correct state before the transaction is executed, and the data in the database is still in the correct state after the transaction is executed , that is, the data integrity constraint is not broken
        • For example, bank transfer, A transfers money to B, it must be ensured that A's money must be transferred to B, and there must be no case that A's money is transferred but B does not receive it, otherwise the data in the database will be in an inconsistent (incorrect) state
      • Isolation
      • • There is no impact between concurrent transaction executions, and operations within one transaction have no impact on other transactions , which requires transaction isolation level to specify isolation
      • Durability
      • • Once the transaction is successfully executed, its changes to the data in the database must be permanent , and there will be no data inconsistency or loss due to, for example, a system failure or power failure .
    • common problem
    • • lost updates,
      • • Two transactions update a row of data at the same time, and the update of the last transaction will overwrite the update of the first transaction, resulting in the loss of the data updated by the first transaction, which is caused by the lack of locking.
      • dirty read
      • • One transaction has seen uncommitted updates from another transaction
      • non-repeatable read,
      • • In the same transaction, reading the same data multiple times returns different results; that is, other transactions have changed the data
        • The point of non-repeatable read is to modify
      • hallucinations
      • • During execution, a transaction reads the inserted data that has been committed by another transaction; that is, a batch of data is read at the beginning of the first transaction, but then another transaction inserts new data and commits it. A transaction reads this batch of data again but finds one more , that is, it seems like a hallucination
        • The point of phantom reading is to add or delete
    • isolation level
    • • Read Uncommitted
      • • The lowest isolation level, a transaction can read the uncommitted update data of other transactions, which is very unsafe, and may have lost updates, dirty reads, non-repeatable reads, and phantom reads.
      • 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 mode focuses on simplifying the interface
    • Adapter mode focuses on converting interfaces
    • Bridge pattern focuses on separating interface (abstract) and its implementation
    • The Decorator pattern focuses on extending functions for objects on the premise of stable interfaces

Reprinted from: http://blog.csdn.net/zhiguozhu/article/details/50517579