Hibernate脏数据检查和缓存清理策略

简述

清理缓存：

对当前持久化状态的缓存数据进行检查，并且将有修改的数据持久化到数据库当中的过程称为“清理缓存”。清理缓存有一定的触发策略。

策略详解：

当一个对象在持久化的时候会添加到session缓存，缓存的同时Hibernate会自动存放一个与当前持久化对象相关的快照（暂时理解成当前持久化对象的一个副本），程序在操作持久化对象的时候并不会修改这个快照，而且修改的数据并不是立即持久化到数据库当中的，而是一直通过缓存的方式放在缓存中，然后通过优化策略执行最少的sql。修改的数据存放在缓存当中也就意味着不安全，因此会有相应的“清理缓存”的触发事件，比如事务提交commit，显式flush等，在“清理缓存”事件触发的时候，Hibernate会自动将当前持久化对象的状态与之前创建的持久化对象的快照进行对比，如果有变化则优化sql并持久化到数据库当中，如果没有变化则无动作。这里要注意：在进行脏数据检查的时候并不是去数据库直接取数据，而是从缓存当中取到之前的快照进行对比，这有效减少了数据库的访问次数。

缓存清理时机：

commit：在调用commit之前会先调用flush清理缓存，然后才真正提交事务。

flush：检查脏数据并执行需要执行的sql。

两者区别：commit在真正提交事务之前调用flush，也就是说，如果没有最终的提交事务这个动作，这两者产生的结果是一样的，都是执行需要执行的sql，但是commit真正提交事务发生以后就是告诉数据库之前提交的数据是永久性的保存到数据库，此时数据库也会清理自身的一些缓存，因为数据库在收到事务提交之前对于执行过的sql仍然有回滚的余地，也就有相应的缓存；flush则是仅仅对数据库执行相应的sql，假设此时宕机，之前提交的数据仍然只是不可靠数据会被清理。

对事务提交的理解：

事务的提交是一个过程，就像在commit之前会调用flush一样，flush只是commit的一个准备阶段，等之前的sql执行完以后，客户端会发送一个前期执行的sql的一个确认，确定这些sql执行是永久性的保存在数据库中，然后数据库可以放心的清理自己的缓存，在flush与真正的commit之间则有一个过度阶段，这个阶段客户端可以发送rollback进行回滚告诉数据库之前执行的sql作废，请数据库通过自己的缓存还原前期的修改。

题外话：

上述中提到，持久化对象的多次修改并不会立即执行相应的sql，而是将修改的数据放在缓存当中，通过“清理缓存”事件的触发而持久化到数据库当中。但是要注意：一般情况下，对于相同的执行动作可以进行合并和优化，比如多条update对同一个持久化对象的操作就可以优化成最终的一条update，这就减少了数据库的访问次数，然而如果是不同的执行动作那就得另外看待，虽然操作的可能是同一个持久化对象，但是操作的动作不一样，一般情况下是不会放在一起优化的，比如save动作和update动作，如果限制性save，然后接着在同一个事务中执行了update动作，这个是不会优化成先执行update然后执行save，而是分别执行并且按照定义的顺序执行。