Spring发展历程总结

  ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ ^_^  ^_^ ^_^ ^_^ 

 ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^ ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^ ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^  ^_^ ^_^  ^_^ ^_^ ^_^ ^_^

　　我通俗的理解如下：spring只是控制数据库的事务提交和回滚，借助于java的反射机制，在事务控制的方法（通常是service层的方法）前后获取事务开启session，然后执行你的数据操作，如果你的方法内有异常被抛出，spring会捕获异常并回滚你在这个方法内所有的数据操作，如果成功则提交所有的数据，最后spring会帮你关闭需要关闭的东西。所以spring想要做的是，要程序员专注于写逻辑，不需要关心数据库何时开启和关闭连接。

　　在SSH框假中Spring充当了管理容器的角色。我们都知道Hibernate用来做持久层，因为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的，他它负责调用业务逻辑serivce层。所以SSH框架的流程大致是：Jsp页面----Struts------Service（业务逻辑处理类）---Hibernate（左到右）。struts负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的依赖很强，属于耦合。这时，使用spring框架就起到了控制Action对象（Strus中的）和Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正是用在此处。
 
　　Spring的Ioc（控制反转和依赖注入） 
控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控 
依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注入到组件之中。 
从上面我们不难看出：从头到尾Action仅仅是充当了Service的控制工具，这些具体的业务方法是怎样实现的，他根本就不会管，也不会问，他只要知道这些业务实现类所提供的方法接口就可以了。而在以往单独使用Struts框架的时候，所有的业务方法类的生命周期，甚至是一些业务流程都是由Action来控制的。层与层之间耦合性太紧密了，既降低了数据访问的效率又使业务逻辑看起来很复杂，代码量也很多。Spring容器控制所有Action对象和业务逻辑类的生命周期，由于上层不再控制下层的生命周期，层与层之间实现了完全脱耦，使程序运行起来效率更高，维护起来也方便。
 
　　使用Spring的第二个好处（AOP应用）： 
事务的处理： 
在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch 来完成，而在Spring中。Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能，包括异常时事务回滚，操作成功时数据提交等复杂业务功能。这都是由Spring容器来管理，大大减少了程序员的代码量，也对事务有了很好的管理控制。Hibernate中也有对事务的管理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。而Spring对SessionFactory配置也进行了整合，不需要在通过hibernate.cfg.xml来对SessionaFactory进行设定。这样的话就可以很好的利用Sping对事务管理强大功能。避免了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的Try/Catch操作。这些也就是Spring中的AOP（面向切面编程）机制很好的应用。一方面使开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng AOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。有利于代码重用，特别是Dao代码的重用。事务往往和业务规则紧密关联。当业务逻辑发生改变，意味着dao的大幅度改动。系统规模达到一定程度，修改风险相当大。Spring的好处是不更改现有的dao，仅需对现有的service bean进行配置就达到事务效果了。同时，把事务统一在service层，系统结构更清晰。

为什么说风险风大？
Spring对于事务的配置有两种方式：第一种，使用xml形式，第二种，使用注解的形式。
基于XMl方式： 优点：可以在后期维护的时候适当的调整事务管理模式，并且只要遵循一定的命名规范，可以让程序员不必关心事务。
　　　　　　  缺点：系统越庞大，xml配置就越大。
基于注解方式：优点：配置比较方便，程序员只要在service层代码设置即可以实现。不需要知道系统需要多少个bean，交给容器来注入就好了。
　　　　　　  缺点：当你要修改或删除一个bean的时候，你无法确定到底有多少个其他的bean依赖于这个bean。(解决方法：需要有严格的开发文档，在修改实现时尽可能继续遵守相应的接口避免使其他依赖于此的bean不可用)

//  Office.java
public class Office {
    private String officeNo =”001”;

    //省略 get/setter

    @Override
    public String toString() {
        return "officeNo:" + officeNo;
    }
}

//  Car.java
public class Car {
    private String brand;
    private double price;

    // 省略 get/setter

    @Override
    public String toString() {
        return "brand:" + brand + "," + "price:" + price;
    }
}

//  Boss.java
public class Boss {
    private Car car;
    private Office office;

    // 省略 get/setter

    @Override
    public String toString() {
        return "car:" + car + "\n" + "office:" + office;
    }
}

//  bean.xml将以上三个类配置成bean。
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
    <bean id="boss" class="com.baobaotao.Boss">
        <property name="car" ref="car"/>
        <property name="office" ref="office" />
    </bean>
    <bean id="office" class="com.baobaotao.Office">
        <property name="officeNo" value="002"/>
    </bean>
    <bean id="car" class="com.baobaotao.Car" scope="singleton">
        <property name="brand" value=" 红旗 CA72"/>
        <property name="price" value="2000"/>
    </bean>
</beans>

//  当我们运行这段代码时，控制台将正确打印出boss的信息。这说明 Spring 容器已经正确完成了 Bean 创建和装配的工作。
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class AnnoIoCTest {

    public static void main(String[] args) {
        String[] locations = {"beans.xml"};
        ApplicationContext ctx = 
            new ClassPathXmlApplicationContext(locations);
        Boss boss = (Boss) ctx.getBean("boss");
        System.out.println(boss);
    }
}

// Autowired是自动装配的意思
import org.springframework.beans.factory.annotation.Autowired;

public class Boss {

    @Autowired
    private Car car;

    @Autowired
    private Office office;
}

// Spring 通过一个 BeanPostProcessor 对 @Autowired 进行解析，所以要让@Autowired 起作用必须事先在 Spring 容器中声明 AutowiredAnnotationBeanPostProcessor Bean。
// 让系统认识@Autowired，让@Autowired注释工作起来。

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <!-- 该 BeanPostProcessor 将自动起作用，对标注 @Autowired 的 Bean 进行自动注入 -->
    <bean class="org.springframework.beans.factory.annotation.
        AutowiredAnnotationBeanPostProcessor"/>

    <!-- 移除 boss Bean 的属性注入配置的信息 -->
    <bean id="boss" class="com.baobaotao.Boss"/>          // 这里面没配置哦
 
    <bean id="office" class="com.baobaotao.Office">
        <property name="officeNo" value="001"/>
    </bean>
    <bean id="car" class="com.baobaotao.Car" scope="singleton">
        <property name="brand" value=" 红旗 CA72"/>
        <property name="price" value="2000"/>
    </bean>
</beans>

这样，当 Spring 容器启动时，AutowiredAnnotationBeanPostProcessor 将扫描 Spring 容器中所有 Bean，当发现 Bean 中拥有@Autowired 注释时就找到和其匹配（默认按类型匹配）的 Bean，并注入到对应的地方中去。按照上面的配置，Spring 将直接采用 Java 反射机制对 Boss 中的

car 和 office 这两个私有成员变量进行自动注入。所以对成员变量使用@Autowired 后，您大可将它们的 setter 方法（setCar() 和 setOffice()）从 Boss 中删除。当然，您也可以通过 @Autowired 对方法或构造函数进行标注，来看下面的代码：

public class Boss {
    private Car car;
    private Office office;

     @Autowired
    public void setCar(Car car) {
        this.car = car;
    }
 
    @Autowired
    public void setOffice(Office office) {
        this.office = office;
    }
}

这时，@Autowired 将查找被标注的方法的入参类型的 Bean，并调用方法自动注入这些 Bean。而下面的使用方法则对构造函数进行标注：

　Spring IOC三种注入方式（接口注入、setter注入、构造器注入）

public class Boss {
    private Car car;
    private Office office;
 
    @Autowired
    public Boss(Car car ,Office office){
        this.car = car;
        this.office = office ;
    }
}

// 由于 Boss() 构造函数有两个入参，分别是 car 和 office，@Autowired 将分别寻找和它们类型匹配的 Bean，将它们作为Boss(Car car ,Office office) 的入参来创建 Boss Bean。

在默认情况下使用 @Autowired 注释进行自动注入时，Spring 容器中匹配的候选 Bean 数目必须有且仅有一个。当找不到一个匹配的 Bean 时，Spring 容器将抛出BeanCreationException 异常，并指出必须至少拥有一个匹配的 Bean。我们可以来做一个实验：

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/beans/spring-beans-2.5.xsd ">
 
    <bean class="org.springframework.beans.factory.annotation.
        AutowiredAnnotationBeanPostProcessor"/> 

    <bean id="boss" class="com.baobaotao.Boss"/>

    <!-- 将 office Bean 注释掉 -->
    <!-- <bean id="office" class="com.baobaotao.Office">             //然后你想，当多个bean之间互相依赖的时候，是不是维护起来很麻烦啊。
    <property name="officeNo" value="001"/>
    </bean>-->

    <bean id="car" class="com.baobaotao.Car" scope="singleton">
        <property name="brand" value=" 红旗 CA72"/>
        <property name="price" value="2000"/>
    </bean>
</beans>

由于 office Bean 被注释掉了，所以 Spring 容器中将没有类型为 Office 的 Bean 了，而 Boss 的office 属性标注了 @Autowired，当启动 Spring 容器时，异常就产生了。当不能确定 Spring 容器中一定拥有某个类的 Bean 时，可以在需要自动注入该类 Bean 的地方可以使用 @Autowired(required = false)，这等于告诉 Spring：在找不到匹配 Bean 时也不报错。来看一下具体的例子：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Required;

public class Boss {

    private Car car;
    private Office office;

    @Autowired
    public void setCar(Car car) {
        this.car = car;
    }
    @Autowired(required = false)
    public void setOffice(Office office) {
        this.office = office;
    }
}

当然，一般情况下，使用 @Autowired 的地方都是需要注入 Bean 的，使用了自动注入而又允许不注入的情况一般仅会在开发期或测试期碰到（如为了快速启动 Spring 容器，仅引入一些模块的 Spring 配置文件），所以@Autowired(required = false) 会很少用到。和找不到一个类型匹配 Bean 相反的一个错误是：如果 Spring 容器中拥有多个候选 Bean，Spring 容器在启动时也会抛出 BeanCreationException 异常。来看下面的例子：

// 在 beans.xml 中配置两个 Office 类型的 Bean
<bean id="office" class="com.baobaotao.Office">
    <property name="officeNo" value="001"/>
</bean>
<bean id="office2" class="com.baobaotao.Office">
    <property name="officeNo" value="001"/>
</bean>

我们在 Spring 容器中配置了两个类型为 Office 类型的 Bean，当对 Boss 的 office 成员变量进行自动注入时，Spring 容器将无法确定到底要用哪一个 Bean，因此异常发生了。Spring 允许我们通过 @Qualifier 注释指定注入 Bean 的名称，这样歧义就消除了，可以通过下面的方法解决异常：

@Autowired
public void setOffice(@Qualifier("office")Office office) {
    this.office = office;
}

@Qualifier("office") 中的 office 是 Bean 的名称，所以 @Autowired 和@Qualifier 结合使用时，自动注入的策略就从 byType 转变成 byName 了。@Autowired 可以对成员变量、方法以及构造函数进行注释，而@Qualifier 的标注对象是成员变量、方法入参、构造函数入参。正是由于注释对象的不同，所以 Spring 不将 @Autowired 和@Qualifier 统一成一个注释类。下面是对成员变量和构造函数入参进行注释的代码：对成员变量进行注释：

public class Boss {
    @Autowired
    private Car car;
 
    @Autowired
    @Qualifier("office")
    private Office office;
}

 我们面试中提到Spring框架经常被问到的一块儿是Spring的事务，它优于struts2，优于hibernate。那么我们现在就详细的说说这个东西。

// 事务的特性：原子性、一致性、隔离性、持久性。

常常问的：1. Spring事务的传播特性; 2. Spring事务的隔离机制。

 我们先来探讨一下数据库事务的隔离级别：

事务的（ACID）特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的。数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。

幻读 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的“全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样.一般解决幻读的方法是增加范围锁RangeS，锁定检锁范围为只读，这样就避免了幻读。

脏读 就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

　数据库系统有四个隔离级别。对数据库使用何种隔离级别要审慎分析，因为维护一个最高的隔离级别虽然会防止数据的出错，但是却导致了并行度的损失，以及导致死锁出现的可能性增加。然而，降低隔离级别，却会引起一些难以发现的bug。

　　1. 序列化 Serializable, 添加范围锁（比如表锁，页锁等，关于range lock，我也没有很深入的研究），直到transaction A结束。以此阻止其它trasaction B对此范围内的insert，update等操作。幻读，脏读，不可重复读等问题都不会发生。

 

　　2. 可重复读 repeatable read, 对于读出的记录，添加共享锁直到transaction A结束。其它transaction B对这个记录的试图修改会一直等待直到trasaction A结束。InnoDB 默认级别。可能发生的问题：当执行一个范围查询时，可能会发生幻读。

 

　　3. 提交读 read commited, 在trasaction A中读取数据时对记录添加共享锁，但读取结束立即释放。其它transaction B对这个记录的试图修改会一直等待直到A中的读取过程结束，而不需要整个trasaction A的结束。所以，在trasaction A的不同阶段对同一记录的读取结果可能是不同的。

       可能发生的问题：不可重复读。

 

　　4. 未提交读 read uncommited, 不添加共享锁。所以其它trasaction B可以在trasaction A对记录的读取过程中修改同一记录，可能会导致A读取的数据是一个被破坏的或者说不完整不正确的数据。另外，在trasaction A中可以读取到trasaction B（未提交）中修改的数据。比如trasaction 　　　　B对R记录修改了，但未提交。此时，在Trasaction A中读取R记录，读出的是被B修改过的数据。可能发生的问题：脏读。

 那么Spring的事务隔离机制和Spring事务的传播属性呢，Spring的隔离级别我们知道目的是为了防止幻读和脏读。Spring的事务传播属性似乎好难理解。。接下来，先解释下什么叫做事务的传播属性：

我们都知道事务的概念，那么事务的传播特性是什么呢？(先着重介绍传播特性的概念，关于传播特性的相关配置稍后再介绍)
背景：当我们用SSH开发项目的时候，我们一般都是将事务设置在Service层 那么当我们调用Service层的一个方法的时候它能够保证我们的这个方法中执行的所有的对数据库的更新操作保持在一个事务中，在事务层里面调用的这些方法要么全部成功，要么全部失败。那么事务的传播特性也是从这里说起的。
场景：如果你在你的Service层的这个方法中，除了调用了Dao层的方法之外，还调用了本类的其他的Service方法，那么在调用其他的Service方法的时候，这个事务是怎么规定的呢，我必须保证我在我方法里掉用的这个方法与我本身的方法处在同一个事务中，否则如何保证事物的一致性。事务的传播特性就是解决这个问题的，“事务是会传播的”在Spring中有针对传播特性的多种配置我们大多数情况下只用其中的1种:PROPGATION_REQUIRED：这个配置项的意思是说当我调用service层的方法的时候开启一个事务(具体调用那一层的方法开始创建事务，要看你的aop的配置),那么在调用这个service层里面的其他的方法的时候,如果当前方法产生了事务就用当前方法产生的事务，否则就创建一个新的事务。这个工作使由Spring来帮助我们完成的。
以前没有Spring帮助我们完成事务的时候我们必须自己手动的控制事务，例如当我们项目中仅仅使用hibernate，而没有集成进spring的时候，我们在一个service层中调用其他的业务逻辑方法，为了保证事物必须也要把当前的hibernate session传递到下一个方法中，或者采用ThreadLocal的方法，将session传递给下一个方法，其实都是一个目的。现在这个工作由spring来帮助我们完成，就可以让我们更加的专注于我们的业务逻辑。而不用去关心事务的问题。默认情况下当发生RuntimeException的情况下，事务才会回滚，所以要注意一下如果你在程序发生错误的情况下，有自己的异常处理机制定义自己的Exception，必须从RuntimeException类继承这样事务才会回滚！

好了，知道了事务的传播特性之后，我们看看Spring提供的六种事务传播Propagation特性：仔细感觉一下，六中Spring事务传播机制 对称美 

1. Propagation required, 如果当前没有事务，就新建一个事务。
2. Propagation supports, 如果当前没有事务，就以非事务方式执行。
3. Propagation mandatory, 如果当前没有事务，就抛出异常。
4. Propagation requires new, 如果当前存在事务，挂起当前事务，新建事务。
5. Propagation not supported, 如果当前存在事务，把当前事务挂起，以非事务方式执行。
6. Propagation never, 如果当前存在事务，抛出异常。以非事务方式执行。

关于六种事务传播机制的具体应用场景，参考： Spring事务传播机制博客

 了解了Spring事务的传播特性，再来看看Spring事务的五种隔离级别isolation level。

// 先再来回顾前面说到的三个概念
脏读: 指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。
    
不可重复读: 指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
            
幻觉读: 指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

// 再来看Spring事务的隔离级别isolation level：

 1. isolation default： 这是一个默认的隔离级别，使用数据库默认的事务隔离级别.(一般情况下，使用这种)。另外四个与JDBC的隔离级别相对应.

 2. isolation read uncommited： 这个是事务最低的隔离级别，它允许令外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。(trasaction B可以在trasaction A对记录的读取过程中修改同一记录)
　　 产生脏读、产生不重复读、产生幻读。

 3. isolation read commited： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据.(trasaction B提交后trasaction A才能读取)
　　 避免脏读、会产生不重复读、会产生幻读。

 4. isolation repeatable read： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
　　 避免脏读、避免不重复读、会产生幻读。

 5. isolation serializable.这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。 除了防止脏读，不可重复读外，还避免了幻读。
　　 避免脏读、避免不重复读、避免幻读。

1.客户端请求提交到DispatcherServlet
2. 由DispatcherServlet控制器查询一个或多个HandlerMapping，找到处理请求的Controller
3. DispatcherServlet将请求提交到Controller
4. Controller调用业务逻辑处理后，返回ModelAndView
5. DispatcherServlet查询一个或多个ViewResoler视图解析器，找到ModelAndView指定的视图
6. 视图负责将结果显示到客户端

介绍一下Spring的事务管理 
事务就是对一系列的数据库操作（比如插入多条数据）进行统一的提交或回滚操作，如果插入成功，那么一起成功，如果中间有一条出现异常，那么回滚之前的所有操作。这样可以防止出现脏数据，防止数据库数据出现问题。开发中为了避免这种情况一般都会进行事务管理。Spring中也有自己的事务管理机制，一般是使用TransactionMananger进行管理，可以通过Spring的注入来完成此功能。

什么是依赖注入，依赖注入的作用是什么? 
IOC是一种思想，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试. 有了IOC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

依赖注入的作用：减少类间耦合度，避免用new来创建对象。

什么是AOP，AOP的作用是什么? 
AOP，面向切面编程，就是把可重用的功能提取出来，然后将这些通用功能在合适的时候织入到应用程序中，比如事务管理、权限控制、日志记录、性能统计等。

AOP的作用
AOP并没有帮助我们解决任何新的问题，它只是提供了一种更好的办法，能够用更少的工作量来解决现有的一些问题，使得系统更加健壮，可维护性更好。

1、BeanFactory负责读取bean的配置文件，管理bean的加载、实例化，维护bean之间的依赖关系，负责bean的生命周期。 
2、ApplicationContext除了提供上述BeanFactory所能提供的功能之外，还提供了更完整的框架功能： 
a. 国际化支持
b. 资源访问
c. 事件传递

Hibernate工作原理及为什么要用？ 
原理： 
1.读取并解析配置文件 
2.读取并解析映射信息，创建SessionFactory 
3.打开Sesssion 
4.创建事务Transation 
5.持久化操作 
6.提交事务 
7.关闭Session 
8.关闭SesstionFactory

// 为什么要用： 
1. 对JDBC访问数据库的代码做了封装，大大简化了数据访问层繁琐的重复性代码。 
2. Hibernate是一个基于JDBC的主流持久化框架，是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作 
3. hibernate使用Java反射机制，而不是字节码增强程序来实现透明性。 
4. hibernate的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。它支持各种关系数据库，从一对一到多对多的各种复杂关系。

Hibernate是如何延迟加载? 
1. Hibernate2延迟加载实现：a)实体对象 b)集合（Collection） 
2. Hibernate3 提供了属性的延迟加载功能 
当Hibernate在查询数据的时候，数据并没有存在与内存中，当程序真正对数据的操作时，对象才存在与内存中，就实现了延迟加载，他节省了服务器的内存开销，从而提高了服务器的性能。

Hibernate中怎样实现类之间的关系?(如：一对多、多对多的关系)

类与类之间的关系主要体现在表与表之间的关系进行操作，它们都是对对象进行操作，我们程序中把所有的表与类都映射在一起，它们通过配置文件中的many-to-one、one-to-many、many-to-many、

详细说下hibernate的缓存机制：


 // 为什么要用hibernate缓存：

Hibernate是一个持久层框架，经常访问物理数据库。为了降低应用程序对物理数据源访问的频次，从而提高应用程序的运行性能。缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻或事件会同步缓存和物理数据源的数据。

 // Hibernate的缓存原理是怎么样的？

Hibernate一级缓存又称为“Session的缓存”。Session的缓存是事务范围的缓存（Session对象的生命周期通常对应一个数据库事务或者一个应用事务）。

Hibernate二级缓存又称为“SessionFactory的缓存”。由于SessionFactory对象的生命周期和应用程序的整个过程对应，因此Hibernate二级缓存是进程范围或者集群范围的缓存，有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。第二级缓存是可选的，是一个可配置的插件，默认下SessionFactory不会启用这个插件。

   // 既然二级缓存是进程级别的缓存，那么它适合缓存什么类型的数据呢？

　　　　　　什么样的数据适合存放到第二级缓存中？ 　　
　　　　　　　　　　1) 很少被修改的数据 　　
　　　　　　　　　　2) 不是很重要的数据，允许出现偶尔并发的数据 　　
　　　　　　　　　　3) 不会被并发访问的数据 　　
　　　　　　　　　　4) 常量数据 　　
　　不适合存放到第二级缓存的数据？ 　　
　　　　　　　　　　1) 经常被修改的数据 　　
　　　　　　　　　　2) 绝对不允许出现并发访问的数据，如财务数据，绝对不允许出现并发 　　
　　　　　　　　　　3) 与其他应用共享的数据。

　　// Session的延迟加载

　　Session的延迟加载实现要解决两个问题：正常关闭连接和确保请求中访问的是同一个session。Hibernate session就是java.sql.Connection的一层高级封装，一个session对应了一个Connection。http请求结束后正确的关闭session（过滤器实现了session的正常关闭）；延迟加载必须保证是同一个session（session绑定在ThreadLocal）。

　　// Hibernate查找对象, 如何应用缓存？

当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；如果都查不到，再查询数据库，把结果按照ID放入到缓存删除、更新、增加数据的时候，同时更新缓存。

package com.bluesky.spring.dao;  
  
import java.util.List;  
  
import org.hibernate.SessionFactory;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;  
import org.springframework.stereotype.Component;  
  
import com.bluesky.spring.domain.User;  
  
@Transactional    // 看代码(关于事务的配置)
@Component("userDao")  
public class UserDaoImpl extends HibernateDaoSupport implements UserDao {  
    public List<User> listUsers() {  
        return this.getSession().createQuery("from User").list();  
    }      
} 

// 在DAO层上加了注解 @Transactional ，这种申明式事务方式，让我们从复杂的事务处理中得到解脱，使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。

// TransactionDefinition    
public interface TransactionDefinition {    
      int getPropagationBehavior();    //方法 返回事务的传播行为，是否由一个活动事务来决定一个事务的调用。
      int getTimeout();     //方法 返回事务必须在多少秒内执行
      boolean isReadOnly();    //方法返回事务是否是只读的　

　　　 int getIsolationLevel();    // 返回事务的隔离级别

} 

说说事务的隔离级别：在TransactionDefinition接口中定义了五个不同的事务隔离级别，ISOLATION_DEFAULT 这是一个默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应。ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。 

例如: 
  Mary的原工资为1000,财务人员将Mary的工资改为了8000，但未提交事务 

Java代码  

1. Connection con1 = getConnection();  

2. con.setAutoCommit(false);  

3. update employee set salary = 8000 where empId ="Mary";  


与此同时，Mary正在读取自己的工资 

Java代码  

1. Connection con2 = getConnection();  

2. select  salary from employee where empId ="Mary";  

3. con2.commit();  



Mary发现自己的工资变为了8000，欢天喜地！ 
而财务发现操作有误，而回滚了事务,Mary的工资又变为了1000 

Java代码  

1. //con1  

2.   con1.rollback();  


像这样,Mary记取的工资数8000是一个脏数据。 

ISOLATION_READ_COMMITTED  保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。ISOLATION_REPEATABLE_READ  这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。 

在事务1中，Mary 读取了自己的工资为1000,操作并没有完成 
Java代码  
1. con1 = getConnection();  

2. select salary from employee empId ="Mary";  

在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务. 
Java代码  
1. con2 = getConnection();  

2. update employee set salary = 2000;  

3. con2.commit();  

在事务1中，Mary 再次读取自己的工资时，工资变为了2000 
Java代码  
1. //con1  

2. select salary from employee empId ="Mary";  

在一个事务中前后两次读取的结果并不致，导致了不可重复读。 
使用ISOLATION_REPEATABLE_READ可以避免这种情况发生。 

ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。 

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans">
    <!-- 数据源 -->
    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <property name="url" value="jdbc:mysql://192.168.0.244:3306/test?useUnicode=true&amp;characterEncoding=UTF-8" />
        <property name="username" value="root" />
        <property name="password" value="root" />
        <!-- 连接池启动时的初始值 -->
        <property name="initialSize" value="10" />
        <!-- 连接池的最大值 -->
        <property name="maxActive" value="10" />
        <!-- 最大空闲值.当经过一个高峰时间后，连接池可以慢慢将已经用不到的连接慢慢释放一部分，一直减少到maxIdle为止 -->
        <property name="maxIdle" value="20" />
        <!--  最小空闲值.当空闲的连接数少于阀值时，连接池就会预申请去一些连接，以免洪峰来时来不及申请 -->
        <property name="minIdle" value="10" />
        <property name="defaultAutoCommit" value="true" />
    </bean>
    <!-- 会话工厂 -->
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="mappingLocations">
            <list>
                <value>classpath:/com/nms/entity/**/*.hbm.xml</value>
            </list>
        </property>
        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.dialect"> org.hibernate.dialect.MySQL5Dialect </prop>
                <prop key="hibernate.show_sql">true</prop>
                <prop key="hibernate.format_sql">true</prop>
            </props>
        </property>
    </bean>    
    <!-- 定义事务管理器 -->  
    <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>
    <!-- 配置服务层 -->
    <bean id="userDaoAgency" class="com.dao.impl.UserDaoImpl">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>    
    <bean id="userDao" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">  
        <!-- 配置事务管理器 -->  
        <property name="transactionManager" ref="transactionManager" />     
        <property name="target" ref="userDaoAgency" />  
        <property name="proxyInterfaces" value="com.dao.UserDao" />
        <!-- 配置事务属性 -->  
        <property name="transactionAttributes">  
            <props>  
                <prop key="*">PROPAGATION_REQUIRED</prop>
            </props>  
        </property>  
    </bean>
</beans>

<?xml version="1.0" encoding="UTF-8"?>
<beans>
    <!-- 数据源 -->
    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <!-- // 配置同上 -->
    </bean>
    <!-- 会话工厂 -->
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <!-- // 配置同上 -->
    </bean>
    <!-- 定义事务管理器 -->
    <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>
     <!-- 定义事务 -->
    <bean id="base" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" lazy-init="true" abstract="true">
        <!-- 配置事务管理器 -->
        <property name="transactionManager" ref="transactionManager" />
        <!-- 配置事务属性 -->
        <property name="transactionAttributes">
            <props>
                <prop key="*">PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    </bean>
    <!-- 配置服务层 -->
    <bean id="userDao" class="com.dao.impl.UserDaoImpl">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>
    <!-- 代理对象 -->
    <bean id="userDaoAgency" parent="base">
        <property name="target" ref="userDao" />
    </bean>
</beans>