Hibernate中的脏检查和缓存清理机制
脏检查
Session到底是如何进行脏检查的呢？当一个Customer对象被加入到Session缓存中时，Session会为Customer对象的值类型的属性复制一份快照。当Session清理缓存时，会先进行脏检查，即比较Customer对象的当前属性与它的快照，来判断Customer对象的属性是否发生了变化，如果发生了变化，就称这个对象是“脏对象”，Session会根据脏对象的最新属性来执行相关的SQL语句，从而同步更新数据库。
脏数据检查：
什么是脏数据？脏数据并不是废弃和无用的数据，而是状态前后发生变化的数据。我们看下面的代码：
Transaction tx=session.beginTransaction();
User user=(User)session.load(User.class,”1”);//从数据库中加载符合条件的数据
user.setName(“zz”);//改变了user对象的姓名属性，此时user对象成为了所谓的“脏数据”
tx.commit();
当事务提交时，Hibernate会对session中的PO(持久化对象)进行检测，判断持久化对象的状态是否发生了改变，如果发生了改变就会将改变更新到数据库中。这里就存在一个问题，Hibernate如何来判断一个实体对象的状态前后是否发生了变化。也就是说Hibernate是如何检查出一个数据已经变脏了。
通常脏数据的检查有如下两种办法：
A、数据对象监控：
数据对象监控是通过拦截器对数据对象的setter方法进行监控来实现的，这类似于数据库中的触发器的概念，当某一个对象的属性调用了setter方法而发生了改变，这时拦截器会捕获这个动作，并且将改属性标志为已经改变，在之后的数据库操作时将其更新到数据库中。这个方法的优点是提高了数据更新的同步性，但是这也是它的缺点，如果一个实体对象有很多属性发生了改变，势必造成大量拦截器回调方法的调用，这些拦截器都是通过Dynamic Proxy或者CGLIB实现的，在执行时都会付出一定的执行代价，所以有可能造成更新操作的较大延时。
B、数据版本比对:
这种方法是在持久化框架中保存数据对象的最近读取版本，当提交数据时将提交的数据与这个保存的版本进行比对，如果发现发生了变化则将其同步跟新到数据库中。这种方法降低了同步更新的实时性，但是当一个数据对象的很多属性发生改变时，由于持久层框架缓存的存在，比对版本时可以充分利用缓存，这反而减少了更新数据的延迟。
在Hibernate中是采用数据版本比对的方法来进行脏数据检查的，我们结合下面的代码来讲解Hibernate的具体实现策略。
Transaction tx=session.beginTransaction();
User user=(User)session.load(User.class,”1”);
user.setName(“zz”);
tx.commit();
当调用tx.commit();时好戏就此开场，commit()方法会调用session.flush()方法，在调用flush()方法时，会首先调用flushEverything()来进行一些预处理（如调用intercepter,完成级联操作等），然后调用flushEntities()方法，这个方法是进行脏数据检查的关键。
在继续讲解之前，我要先来介绍一个内部数据结构EntityEntry,EntityEntry是从属于SessionImpl(Session接口的实现类)的内部类，每一个EntityEntry保存了最近一次与数据库同步的实体原始状态信息（如：实体的版本信息，实体的加锁模式，实体的属性信息等）。除了EntityEntry结构之外，还存在一个结构，这个结构称为EntityEntries，它也是SessionImpl的内部类，而且是一个Map类型，它以”key-value”的形式保存了所有与当前session实例相关联的实体对象和原始状态信息，其中key是实体对象，value是EntityEntry。而flushEntities()的工作就是遍历entityEntities,并将其中的实体对象与原始版本进行对比，判断实体对象是否发生来了改变。flushEntities()首先会判断实体的ID是否发生了改变，如果发生了改变则认为发生了异常，因为当前实体与EntityEntry的对应关系非法。如果没有发生异常，而且经过版本比对判断确实实体属性发生了改变，则向当前的更新任务队列中加入一个新的更新任务，此任务将在将在session.flush()方法中的execute()方法的调用中，转化为相应的SQL语句交由数据库去执行。最后Transaction将会调用当前session对应的JDBC Connection的commit()方法将当前事务提交。
脏数据检查是发生在显示保存实体对象时，所谓显示保存是指在代码中明确使用session调用save,update,saveOrupdate方法对实体对象进行保存，如：session.save(user);但是有时候由于级联操作的存在，会产生一个问题，比如当保存一个user对象时，会根据user对象的状态来对他所关联的address对象进行保存，但是此时并没有根据级联对象的显示保存语句。此时需要Hibernate能根据当前对象的状态来判断是否要将级联对象保存到数据库中。此时，Hibernate会根据unsaved-value进行判断。Hibernate将首先取出目标对象的ID，然后将ID与unsaved-value值进行比较，如果相等，则认为实体对象尚未保存，进而马上将进行保存，否则，则认为实体对象已经保存，而无须再次进行保存。比如，当向一个user对象新加入一个它所关联的address对象后，当进行session.save(user)时，Hibernate会根据unsaved-value的值判断出哪个address对象需要保存，对于新加入的address对象它的id尚未赋值，以此为null，与unsaved-value值相等，因此Hibernate会将其视为未保存对象，生成insert语句加以保存。如果想使用unsaved-value必须如下配置address对象的id属性：
……
<id name=”id” type=”java.lang.Integer” unsaved-value=”null”>
<generator class=”increment”/>
</id>
……
缓存清理机制
当Session缓存中对象的属性每次发生了变化，Session并不会立即清理缓存和执行相关的SQL update语句，而是在特定的时间点才清理缓存，这使得Session能够把几条相关的SQL语句合并为一条SQL语句，一遍减少访问数据库的次数，从而提高应用程序的数据访问性能。
在默认情况下，Session会在以下时间点清理缓存。
- 当应用程序调用org.hibernate.Transaction的commit()方法的时候.commit方法先清理缓存，然后再向数据库提交事务。Hibernate之所以把清理缓存的时间点安排在事务快结束时，一方面是因为可以减少访问数据库的频率，还有一方面是因为可以尽可能缩短当前事务对数据库中相关资源的锁定时间。
- 当应用程序执行一些查询操作时，如果缓存中持久化对象的属性已经发生了变化，就会清理缓存，使得Session缓存与数据库已经进行了同步，从而保证查询结果返回的是正确的数据。
- 当应用程序显示调用Session的flush()方法的时候。
Session进行清理缓存的例外情况是，如果对象使用native生成器来生成OID，那么当调用Session的save()方法保存该对象时，会立即执行向数据库插入该实体的insert语句。
