簡述

清理快取：

對當前持久化狀態的快取資料進行檢查，並且將有修改的資料持久化到資料庫當中的過程稱為“清理快取”。清理快取有一定的觸發策略。

策略詳解：

當一個物件在持久化的時候會新增到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，而是分別執行並且按照定義的順序執行。