在瞭解此文前，請首先閱讀：

    在使用hibernate時，我們還是很有必要將hibernate的內部實現原理來搞清楚一下的。比如，hibernate在儲存一個物件時，
    它的內部實現原理是怎樣的。當然要想清楚的瞭解這些，就必須要從它的主鍵生成策略出發來一步一步深入探究!

一、儲存物件簡單原理

在通過hibernate來儲存一個物件時，要先了解它內部的原理：

1、save：

此方法在執行時，會先把一個物件放在session快取中

(當然可以巨集觀上先這麼理解，會有意外，這個意外也是這篇部落格介紹的重點)

於此同時，在快取中還會再生成一個臨時物件的快取區，在這塊臨時區域中會在進行資料庫操作時，與session中的物件進行對比，最後 生成sql語句。
（在session快取區中會有一個isDatabase這個標識來標記當前資料是否已經存在資料庫中）
 

2、commit

    預設在執行完save之後，資料其實並沒有真正的到達資料庫（有意外），通常在執行完commit之後，才會是真正意義上的物件儲存。
    但是預設情況下，在執行commit之前，hibernate會自動先執

flush方法，此方法用來根據臨時物件快取區生成sql語句，操作資料庫

    並清理session快取區。完成真正的資料插入操作。

二、主鍵生成策略

    這裡並不是想一一介紹主鍵有哪些生成策略，而是想簡單的瞭解一下主鍵的生成方式都是由什麼來決定的，會造成什麼影響。

1、uuid：

    主要是通過hibernate生成，效率較高。所以此中方式儲存物件時，在執行完save後，就會為物件的主鍵進行賦值。
    只有在執行完commit或者顯式執行flush之後才會生成sql並清理快取，形成真正意義上的資料儲存
 

2、native（下面就是意外）

    通過不同資料庫的能力來生成主鍵。所以效率相對較差。
在執行完save方法之後，由於他要去資料庫中生成id，所以此時會直接生成sql並清理快取。如果你的資料庫隔離級別設定為不提交讀時，
在未執行完commit方法之前就可以從資料庫中查到資料了。

3、assigned

    此種方式一種會涉及到

三、顯式呼叫flush方法

    上面說了hibernate中在執行commit時，會預設先執行flush，似乎平時用不到顯式呼叫，那麼什麼時候才會用到flush的顯式呼叫呢？

1、evict方法

    此方法是用來清理session快取區的。
    當我們在程式中呼叫save方法後，有時需要呼叫evict方法來清理session快取區。但此時再執行commit方法時，hibernate會報執行緒
不安全的錯誤。
首先分析下原因：
 

正常情況下：

    save之後，執行commit時，先執行flush方法，根據臨時物件區域生成sql語句，然後清理掉臨時物件區域，
會返回到session中修改isDatabase標記，修改完成後再清理session快取區。

save之後執行evict情況

    此時，剛執行完save後，就執行evict方法，會先清理session快取，也就是說isDatabase標記已經不存在了，那麼當再執行commit時，
預設先執行flush方法時，會去修改session快取區中的isDatabase標記，此時，標記找不到，因此會報錯。

解決方案

    我們可以通過在save方法執行完成之後，顯式執行flush方法，此時，會先進行資料真實儲存，再清理session，這樣就不會再報錯了。

2、assigned手動分配與業務邏輯相結合

    如果主鍵配置為assigned，那麼在業務邏輯中如果出現需要按順序執行insert,update,insert這三個語句時，我們發現在commit之後，
hibernate生成語句的順序為：insert，insert，update
那麼此時，就與我們的設想偏離，若想按照原來的順序執行，此時就可以通過顯式執行flush方法來先將前兩個語句進行執行，再去執行最後一個語句。

總結

主鍵的生成與hibernate的實現原理息息相關。同時flush方法的使用也對具體的程式開發起到很重要的作用。同時瞭解hibernate
中具體操作的實現原理對於理解hibernate和程式開發中的優化也有很大的幫助