hibernate緩存插件

① java中緩存的問題，session，hibernate的緩存，二級緩存，以及我們把常用的的數據緩存下來，有什麼分別

sessiono由session工廠創建，是一個非常重要的對象，它可以開啟事務（業務中必須用到的），對數據進行增刪改查，創建hql，創建原生sql，創建qbc，等，主要是跟資料庫一級to,po,do對象打交道。

首先設置緩存的目的就是為了減少伺服器壓力提高用戶訪問速度。換才能就好像是我們的內存一樣，而資料庫就好像我們的硬碟一樣，從內存中拿數據肯定要比從硬碟中拿數據快的多。
一級緩存又名session級緩存，就是hibernate查詢資料庫後將查詢結果存放在緩存中，這樣下一次查詢相同數據時就不會從資料庫中拿數據，就可以直接在緩存中拿數據，加快了訪問速度。因為從資料庫中拿數據時費時費力的所以有了緩存就大大減小了伺服器壓力。

hibernate支持二級緩存，但是需要第三方插件。需要手動開啟，二級緩存要比一級緩存范圍大。我說的范圍大是指生存周期大。通常存放一些訪問頻率高但是需要更改的次數少的數據。它的存放位置是在本地的某個文件夾下（存儲位置可以通過配置文件設置）。
說白了有了緩存我們訪問數據就會很快，減少了伺服器壓力。

② Hibernate的緩存是在何時清除的

除了手動清除外，一級緩存只在同一個session中 有效 ，至於具體何時從內存卸載由Hibernate框架控制，二級緩存是全局性質的，

③ 配置hibernate二級緩存,有幾種方法

19.2.1. 緩存映射（Cache mappings）
類或者集合映射的「<cache>元素」可以有下列形式：

<cache
usage="transactional|read-write|nonstrict-read-write|read-only"
region="RegionName"
include="all|non-lazy"
/> usage(必須)說明了緩存的策略: transactional、 read-write、 nonstrict-read-write或 read-only。

region (可選, 默認為類或者集合的名字(class or collection role name)) 指定第二級緩存的區域名(name of the second level cache region)

include (可選,默認為 all) non-lazy 當屬性級延遲抓取打開時, 標記為lazy="true"的實體的屬性可能無法被緩存

另外(首選?), 你可以在hibernate.cfg.xml中指定<class-cache>和 <collection-cache> 元素。

這里的usage 屬性指明了緩存並發策略（cache concurrency strategy）。

19.2.2. 策略：只讀緩存（Strategy: read only）
如果你的應用程序只需讀取一個持久化類的實例，而無需對其修改， 那麼就可以對其進行只讀 緩存。這是最簡單，也是實用性最好的方法。甚至在集群中，它也能完美地運作。

<class name="eg.Immutable" mutable="false">
<cache usage="read-only"/>
....
</class>19.2.3. 策略:讀/寫緩存（Strategy: read/write）
如果應用程序需要更新數據，那麼使用讀/寫緩存 比較合適。 如果應用程序要求「序列化事務」的隔離級別（serializable transaction isolation level），那麼就決不能使用這種緩存策略。 如果在JTA環境中使用緩存，你必須指定hibernate.transaction.manager_lookup_class屬性的值， 通過它，Hibernate才能知道該應用程序中JTA的TransactionManager的具體策略。 在其它環境中，你必須保證在Session.close()、或Session.disconnect()調用前， 整個事務已經結束。 如果你想在集群環境中使用此策略，你必須保證底層的緩存實現支持鎖定(locking)。Hibernate內置的緩存策略並不支持鎖定功能。

<class name="eg.Cat" .... >
<cache usage="read-write"/>
....
<set name="kittens" ... >
<cache usage="read-write"/>
....
</set>
</class>

④ hibernate工作原理及為什麼要用

hibernate 簡介：
hibernate是一個開源框架，它是對象關聯關系映射的框架，它對JDBC做了輕量級的封裝，而我們java程序員可以使用面向對象的思想來操縱資料庫。
hibernate核心介面
session：負責被持久化對象CRUD操作
sessionFactory:負責初始化hibernate，創建session對象
configuration:負責配置並啟動hibernate，創建SessionFactory
Transaction:負責事物相關的操作
Query和Criteria介面：負責執行各種資料庫查詢

hibernate工作原理：
1.通過Configuration config = new Configuration().configure();//讀取並解析hibernate.cfg.xml配置文件
2.由hibernate.cfg.xml中的<mapping resource="com/xx/User.hbm.xml"/>讀取並解析映射信息
3.通過SessionFactory sf = config.buildSessionFactory();//創建SessionFactory
4.Session session = sf.openSession();//打開Sesssion
5.Transaction tx = session.beginTransaction();//創建並啟動事務Transation
6.persistent operate操作數據，持久化操作
7.tx.commit();//提交事務
8.關閉Session
9.關閉SesstionFactory

為什麼要用hibernate：
1. 對JDBC訪問資料庫的代碼做了封裝，大大簡化了數據訪問層繁瑣的重復性代碼。
2. Hibernate是一個基於JDBC的主流持久化框架，是一個優秀的ORM實現。他很大程度的簡化DAO層的編碼工作
3. hibernate使用Java反射機制，而不是位元組碼增強程序來實現透明性。
4. hibernate的性能非常好，因為它是個輕量級框架。映射的靈活性很出色。它支持各種關系資料庫，從一對一到多對多的各種復雜關系。

Hibernate是如何延遲載入?get與load的區別
1. 對於Hibernate get方法，Hibernate會確認一下該id對應的數據是否存在，首先在session緩存中查找，然後在二級緩存中查找，還沒有就查詢資料庫，數據 庫中沒有就返回null。這個相對比較簡單，也沒有太大的爭議。主要要說明的一點就是在這個版本(bibernate3.2以上)中get方法也會查找二級緩存！
2. Hibernate load方法載入實體對象的時候，根據映射文件上類級別的lazy屬性的配置(默認為true)，分情況討論：
(1)若為true,則首先在Session緩存中查找，看看該id對應的對象是否存在，不存在則使用延遲載入，返回實體的代理類對象(該代理類為實體類的子類，由CGLIB動態生成)。等到具體使用該對象(除獲取OID以外)的時候，再查詢二級緩存和資料庫，若仍沒發現符合條件的記錄，則會拋出一個ObjectNotFoundException。
(2)若為false,就跟Hibernateget方法查找順序一樣，只是最終若沒發現符合條件的記錄，則會拋出一個ObjectNotFoundException。
這里get和load有兩個重要區別:
如果未能發現符合條件的記錄，Hibernate get方法返回null，而load方法會拋出一個ObjectNotFoundException。
load方法可返回沒有載入實體數據的代 理類實例，而get方法永遠返回有實體數據的對象。
(對於load和get方法返回類型：好多書中都說：「get方法永遠只返回實體類」，實際上並不正 確，get方法如果在session緩存中找到了該id對應的對象，如果剛好該對象前面是被代理過的，如被load方法使用過，或者被其他關聯對象延遲加 載過，那麼返回的還是原先的代理對象，而不是實體類對象，如果該代理對象還沒有載入實體數據（就是id以外的其他屬性數據），那麼它會查詢二級緩存或者數 據庫來載入數據，但是返回的還是代理對象，只不過已經載入了實體數據。)
總之對於get和load的根本區別，一句話，hibernate對於 load方法認為該數據在資料庫中一定存在，可以放心的使用代理來延遲載入，如果在使用過程中發現了問題，只能拋異常；而對於get方 法，hibernate一定要獲取到真實的數據，否則返回null。

Hibernate中怎樣實現類之間的關系?(如：一對多、多對多的關系)
類與類之間的關系主要體現在表與表之間的關系進行操作，它們都市對對象進行操作，我們程序中把所有的表與類都映射在一起，它們通過配置文件中的many-to-one、one-to-many、many-to-many、

說下Hibernate的緩存機制：
Hibernate緩存的作用：
Hibernate是一個持久層框架，經常訪問物理資料庫，為了降低應用程序對物理數據源訪問的頻次，從而提高應用程序的運行性能。緩存內的數據是對物理數據源中的數據的復制，應用程序在運行時從緩存讀寫數據，在特定的時刻或事件會同步緩存和物理數據源的數據
Hibernate緩存分類：
Hibernate緩存包括兩大類：Hibernate一級緩存和Hibernate二級緩存
Hibernate一級緩存又稱為「Session的緩存」，它是內置的，意思就是說，只要你使用hibernate就必須使用session緩存。由於Session對象的生命周期通常對應一個資料庫事務或者一個應用事務，因此它的緩存是事務范圍的緩存。在第一級緩存中，持久化類的每個實例都具有唯一的OID。
Hibernate二級緩存又稱為「SessionFactory的緩存」，由於SessionFactory對象的生命周期和應用程序的整個過程對應，因此Hibernate二級緩存是進程范圍或者集群范圍的緩存，有可能出現並發問題，因此需要採用適當的並發訪問策略，該策略為被緩存的數據提供了事務隔離級別。第二級緩存是可選的，是一個可配置的插件，在默認情況下，SessionFactory不會啟用這個插件。

什麼樣的數據適合存放到第二級緩存中？
1 很少被修改的數據
2 不是很重要的數據，允許出現偶爾並發的數據
3 不會被並發訪問的數據
4 常量數據
不適合存放到第二級緩存的數據？
1經常被修改的數據
2 .絕對不允許出現並發訪問的數據，如財務數據，絕對不允許出現並發
3 與其他應用共享的數據。

Hibernate查找對象如何應用緩存？
當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那麼從二級緩存中查；如果都查不到，再查詢資料庫，把結果按照ID放入到緩存
刪除、更新、增加數據的時候，同時更新緩存

Hibernate管理緩存實例
無論何時，我們在管理Hibernate緩存（Managing the caches）時，當你給save()、update()或saveOrUpdate()方法傳遞一個對象時，或使用load()、 get()、list()、iterate() 或scroll()方法獲得一個對象時, 該對象都將被加入到Session的內部緩存中。
當隨後flush()方法被調用時，對象的狀態會和資料庫取得同步。 如果你不希望此同步操作發生，或者你正處理大量對象、需要對有效管理內存時，你可以調用evict() 方法，從一級緩存中去掉這些對象及其集合。

Hibernate的查詢方式
Sql、Criteria,object comptosition
Hql：
1、 屬性查詢
2、 參數查詢、命名參數查詢
3、 關聯查詢
4、 分頁查詢
5、 統計函數

如何優化Hibernate？
1.使用雙向一對多關聯，不使用單向一對多
2.靈活使用單向一對多關聯
3.不用一對一，用多對一取代
4.配置對象緩存，不使用集合緩存
5.一對多集合使用Bag,多對多集合使用Set
6. 繼承類使用顯式多態
7. 表欄位要少，表關聯不要怕多，有二級緩存撐腰

hibernate的開發步驟：
開發步驟
1)搭建好環境
引入hibernate最小的jar包
准備Hibernate.cfg.xml啟動配置文件
2)寫實體類(pojo)
3)為實體類寫映射文件"User.hbm.xml"
在hibernate.cfg.xml添加映射的實體
4)創建庫表
5)寫測試類
獲得Configuration
創建SessionFactory
打開Session
開啟事務
使用session操作數據
提交事務
關閉資源

⑤ hibernate 二級緩存如何使用，還有查詢緩存

有session緩存又叫一級緩存，sessionFactory緩存；其中sessionFactory緩存又分為兩種：一種是內置緩存，一種是外置緩存即二級緩存，存放資料庫數據。
如何使用：
session緩存不需要任何設置，在你openSession時它就自己開始工作了。
外置緩存即二級緩存需要在xml文件中進行配置。
Hibernate緩存分為二級，
第一級存放於session中稱為一級緩存，默認帶有且不能卸載。
第二級是由sessionFactory控制的進程級緩存。是全局共享的緩存，凡是會調用二級緩存的查詢方法 都會從中受益。只有經正確的配置後二級緩存才會發揮作用。同時在進行條件查詢時必須使用相應的方法才能從緩存中獲取數據。比如Query.iterate()方法、load、get方法等。必須注意的是session.find方法永遠是從資料庫中獲取數據，不會從二級緩存中獲取數據，即便其中有其所需要的數據也是如此。
查詢時使用緩存的實現過程為：首先查詢一級緩存中是否具有需要的數據，如果沒有，查詢二級緩存，如果二級緩存中也沒有，此時再執行查詢資料庫的工作。要注意的是：此3種方式的查詢速度是依次降低的。
存在的問題
一級緩存的問題以及使用二級緩存的原因
因為Session的生命期往往很短，存在於Session內部的第一級最快緩存的生命期當然也很短，所以第一級緩存的命中率是很低的。其對系統性能的改善也是很有限的。當然，這個Session內部緩存的主要作用是保持Session內部數據狀態同步。並非是hibernate為了大幅提高系統性能所提供的。
為了提高使用hibernate的性能，除了常規的一些需要注意的方法比如：
使用延遲載入、迫切外連接、查詢過濾等以外，還需要配置hibernate的二級緩存。其對系統整體性能的改善往往具有立竿見影的效果！
（經過自己以前作項目的經驗，一般會有3~4倍的性能提高）

⑥ Hibernate的一級緩存與二級緩存的區別

一級緩存就是Session級別的緩存，一個Session做了一個查詢操作，它會把這個操作的結果放在一級緩存中，如果短時間內這個session（一定要同一個session）又做了同一個操作，那麼hibernate直接從一級緩存中拿，而不會再去連資料庫，取數據。

二級緩存就是SessionFactory級別的緩存，顧名思義，就是查詢的時候會把查詢結果緩存到二級緩存中，如果同一個sessionFactory創建的某個session執行了相同的操作，hibernate就會從二級緩存中拿結果，而不會再去連接資料庫。

⑦ 請簡述Hibernate工作原理

Hibernate工作原理是Configuration讀取Hibernate的配置文件和映射文件中的信息，即載入配置文件和映射文件，並通過Hibernate配置文件生成一個多線程的SessionFactory對象。

然後，多線程SessionFactory對象生成一個線程Session 對象；Session對象生成Query對象或者Transaction對象；可通過Session對象的get()，load()，save()，update()，delete()和saveOrUpdate( )等方法對PO進行載入、保存、更新、刪除等操作。

在查詢的情況下，可通過Session 對象生成一個Query對象，然後利用Query對象執行查詢操作；如果沒有異常，Transaction對象將提交這些操作結果到資料庫中。

(7)hibernate緩存插件擴展閱讀：

Hibernate它對JDBC進行了非常輕量級的對象封裝，它將POJO與資料庫表建立映射關系，是一個全自動的orm框架，hibernate可以自動生成SQL語句，自動執行，使得Java程序員可以隨心所欲的使用對象編程思維來操縱資料庫。

Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序使用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的JaveEE架構中取代CMP，完成數據持久化的重任。

⑧ 什麼是hibernate中的二級緩存

第一級別的緩存是Session級別的緩存，是屬於事務范圍的緩存，由Hibernate管理，一般無需進行干預。第二級別的緩存是SessionFactory級別的緩存，是屬於進程范圍的緩存。

二級緩存也分為了兩種

內置緩存：Hibernate自帶的，不可卸載，通常在Hibernate的初始化階段，Hibernate會把映射元數據和預定義的SQL語句放置到SessionFactory的緩存中。該內置緩存是只讀的。

外置緩存：通常說的二級緩存也就是外置緩存，在默認情況下SessionFactory不會啟用這個緩存插件，外置緩存中的數據是資料庫數據的復制，外置緩存的物理介質可以是內存或者硬碟。

hibernate二級緩存的結構

2.並發訪問策略

transactional

（事務型）

僅在受管理的環境中適用

提供Repeatable Read事務隔離級別

適用經常被讀，很少修改的數據

可以防止臟讀和不可重復讀的並發問題

緩存支持事務，發生異常的時候，緩存也能夠回滾

read-write

（讀寫型）

提供Read Committed事務隔離級別

在非集群的環境中適用

適用經常被讀，很少修改的數據

可以防止臟讀

更新緩存的時候會鎖定緩存中的數據

nonstrict-read-write

（非嚴格讀寫型）

適用極少被修改，偶爾允許臟讀的數據（兩個事務同時修改數據的情況很少見）

不保證緩存和資料庫中數據的一致性

為緩存數據設置很短的過期時間，從而盡量避免臟讀

不鎖定緩存中的數據

read-only

（只讀型）

適用從來不會被修改的數據（如參考數據）

在此模式下，如果對數據進行更新操作，會有異常

事務隔離級別低，並發性能高

在集群環境中也能完美運作

分析：通過上述表格分析如下

適合放入二級緩存中數據

很少被修改

不是很重要的數據，允許出現偶爾的並發問題

不適合放入二級緩存中的數據

經常被修改

財務數據，絕對不允許出現並發問題

與其他應用數據共享的數據

⑨ 如何設置hibernate 緩存

hibernate的一級緩存是由session提供的，因此它只存在session的生命周期中。也就是說session關閉的時候該session所管理的一級緩存也隨之被清除。hibernate的一級緩存是session所內置的，默認開啟，不能被卸載，也不能進行任何配置。在緩存中的對象,具有持久性,session對象負責管理.一級緩存的優點是使用同一個session對象多次查詢同一個數據對象,僅對資料庫查詢一次。一級緩存採用的是Key-Value的MAP方式來實現的。在緩存實體對象時，對象的主關鍵字ID是MAP的Key，實體對象就是對象的值。所以說一級緩存是以實體對象為單位進行存儲的。訪問的時候使用的是主鍵關鍵字ID。一級緩存使用的是自動維護的功能。但可以通過session提供的手動方法對一級緩存的管理進行手動干預。evict()方法用於將某個對象從session的一級緩存中清除。clear()方法用於將session緩存中的方法全部清除。

⑩ hibernate緩存的詳細配置

很多人對二級緩存都不太了解，或者是有錯誤的認識，我一直想寫一篇文章介紹一下hibernate的二級緩存的，今天終於忍不住了。
我的經驗主要來自hibernate2.1版本，基本原理和3.0、3.1是一樣的，請原諒我的頑固不化。

hibernate的session提供了一級緩存，每個session，對同一個id進行兩次load，不會發送兩條sql給資料庫，但是session關閉的時候，一級緩存就失效了。

二級緩存是SessionFactory級別的全局緩存，它底下可以使用不同的緩存類庫，比如ehcache、oscache等，需要設置hibernate.cache.provider_class，我們這里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查詢緩存，加上
hibernate.cache.use_query_cache=true

緩存可以簡單的看成一個Map，通過key在緩存裡面找value。

Class的緩存
對於一條記錄，也就是一個PO來說，是根據ID來找的，緩存的key就是ID，value是POJO。無論list，load還是iterate，只要讀出一個對象，都會填充緩存。但是list不會使用緩存，而iterate會先取資料庫select id出來，然後一個id一個id的load，如果在緩存裡面有，就從緩存取，沒有的話就去資料庫load。假設是讀寫緩存，需要設置：
<cache usage="read-write"/>
如果你使用的二級緩存實現是ehcache的話，需要配置ehcache.xml
<cache name="com.xxx.pojo.Foo" maxElementsInMemory="500" eternal="false" timeToLiveSeconds="7200" timeToIdleSeconds="3600" overflowToDisk="true" />
其中eternal表示緩存是不是永遠不超時，timeToLiveSeconds是緩存中每個元素（這里也就是一個POJO）的超時時間，如果eternal="false"，超過指定的時間，這個元素就被移走了。timeToIdleSeconds是發呆時間，是可選的。當往緩存裡面put的元素超過500個時，如果overflowToDisk="true"，就會把緩存中的部分數據保存在硬碟上的臨時文件裡面。
每個需要緩存的class都要這樣配置。如果你沒有配置，hibernate會在啟動的時候警告你，然後使用defaultCache的配置，這樣多個class會共享一個配置。
當某個ID通過hibernate修改時，hibernate會知道，於是移除緩存。
這樣大家可能會想，同樣的查詢條件，第一次先list，第二次再iterate，就可以使用到緩存了。實際上這是很難的，因為你無法判斷什麼時候是第一次，而且每次查詢的條件通常是不一樣的，假如資料庫裡面有100條記錄，id從1到100，第一次list的時候出了前50個id，第二次iterate的時候卻查詢到30至70號id，那麼30-50是從緩存裡面取的，51到70是從資料庫取的，共發送1+20條sql。所以我一直認為iterate沒有什麼用，總是會有1+N的問題。
（題外話：有說法說大型查詢用list會把整個結果集裝入內存，很慢，而iterate只select id比較好，但是大型查詢總是要分頁查的，誰也不會真的把整個結果集裝進來，假如一頁20條的話，iterate共需要執行21條語句，list雖然選擇若干欄位，比iterate第一條select id語句慢一些，但只有一條語句，不裝入整個結果集hibernate還會根據資料庫方言做優化，比如使用mysql的limit，整體看來應該還是list快。）
如果想要對list或者iterate查詢的結果緩存，就要用到查詢緩存了

查詢緩存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以後不是net.sf的包名了
<cache name="net.sf.hibernate.cache.StandardQueryCache"
maxElementsInMemory="50" eternal="false" timeToIdleSeconds="3600"
timeToLiveSeconds="7200" overflowToDisk="true"/>
<cache name="net.sf.hibernate.cache.UpdateTimestampsCache"
maxElementsInMemory="5000" eternal="true" overflowToDisk="true"/>
然後
query.setCacheable(true);//激活查詢緩存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可選
第二行指定要使用的cacheRegion是myCacheRegion，即你可以給每個查詢緩存做一個單獨的配置，使用setCacheRegion來做這個指定，需要在ehcache.xml裡面配置它：
<cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" />
如果省略第二行，不設置cacheRegion的話，那麼會使用上面提到的標准查詢緩存的配置，也就是net.sf.hibernate.cache.StandardQueryCache

對於查詢緩存來說，緩存的key是根據hql生成的sql，再加上參數，分頁等信息（可以通過日誌輸出看到，不過它的輸出不是很可讀，最好改一下它的代碼）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
參數是"tiger%"，那麼查詢緩存的key*大約*是這樣的字元串（我是憑記憶寫的，並不精確，不過看了也該明白了）：
select * from cat c where c.name like ? , parameter:tiger%
這樣，保證了同樣的查詢、同樣的參數等條件下具有一樣的key。
現在說說緩存的value，如果是list方式的話，value在這里並不是整個結果集，而是查詢出來的這一串ID。也就是說，不管是list方法還是iterate方法，第一次查詢的時候，它們的查詢方式很它們平時的方式是一樣的，list執行一條sql，iterate執行1+N條，多出來的行為是它們填充了緩存。但是到同樣條件第二次查詢的時候，就都和iterate的行為一樣了，根據緩存的key去緩存裡面查到了value，value是一串id，然後在到class的緩存裡面去一個一個的load出來。這樣做是為了節約內存。
可以看出來，查詢緩存需要打開相關類的class緩存。list和iterate方法第一次執行的時候，都是既填充查詢緩存又填充class緩存的。
這里還有一個很容易被忽視的重要問題，即打開查詢緩存以後，即使是list方法也可能遇到1+N的問題！相同條件第一次list的時候，因為查詢緩存中找不到，不管class緩存是否存在數據，總是發送一條sql語句到資料庫獲取全部數據，然後填充查詢緩存和class緩存。但是第二次執行的時候，問題就來了，如果你的class緩存的超時時間比較短，現在class緩存都超時了，但是查詢緩存還在，那麼list方法在獲取id串以後，將會一個一個去資料庫load！因此，class緩存的超時時間一定不能短於查詢緩存設置的超時時間！如果還設置了發呆時間的話，保證class緩存的發呆時間也大於查詢的緩存的生存時間。這里還有其他情況，比如class緩存被程序強制evict了，這種情況就請自己注意了。

另外，如果hql查詢包含select字句，那麼查詢緩存裡面的value就是整個結果集了。

當hibernate更新資料庫的時候，它怎麼知道更新哪些查詢緩存呢？
hibernate在一個地方維護每個表的最後更新時間，其實也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的緩存配置裡面。
當通過hibernate更新的時候，hibernate會知道這次更新影響了哪些表。然後它更新這些表的最後更新時間。每個緩存都有一個生成時間和這個緩存所查詢的表，當hibernate查詢一個緩存是否存在的時候，如果緩存存在，它還要取出緩存的生成時間和這個緩存所查詢的表，然後去查找這些表的最後更新時間，如果有一個表在生成時間後更新過了，那麼這個緩存是無效的。
可以看出，只要更新過一個表，那麼凡是涉及到這個表的查詢緩存就失效了，因此查詢緩存的命中率可能會比較低。

Collection緩存
需要在hbm的collection裡面設置
<cache usage="read-write"/>
假如class是Cat，collection叫children，那麼ehcache裡面配置
<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的緩存和前面查詢緩存的list一樣，也是只保持一串id，但它不會因為這個表更新過就失效，一個collection緩存僅在這個collection裡面的元素有增刪時才失效。
這樣有一個問題，如果你的collection是根據某個欄位排序的，當其中一個元素更新了該欄位時，導致順序改變時，collection緩存裡面的順序沒有做更新。

緩存策略
只讀緩存（read-only）：沒有什麼好說的
讀/寫緩存（read-write）:程序可能要的更新數據
不嚴格的讀/寫緩存（nonstrict-read-write）：需要更新數據，但是兩個事務更新同一條記錄的可能性很小，性能比讀寫緩存好
事務緩存（transactional）：緩存支持事務，發生異常的時候，緩存也能夠回滾，只支持jta環境，這個我沒有怎麼研究過

讀寫緩存和不嚴格讀寫緩存在實現上的區別在於，讀寫緩存更新緩存的時候會把緩存裡面的數據換成一個鎖，其他事務如果去取相應的緩存數據，發現被鎖住了，然後就直接取資料庫查詢。
在hibernate2.1的ehcache實現中，如果鎖住部分緩存的事務發生了異常，那麼緩存會一直被鎖住，直到60秒後超時。
不嚴格讀寫緩存不鎖定緩存中的數據。

使用二級緩存的前置條件
你的hibernate程序對資料庫有獨占的寫訪問權，其他的進程更新了資料庫，hibernate是不可能知道的。你操作資料庫必需直接通過hibernate，如果你調用存儲過程，或者自己使用jdbc更新資料庫，hibernate也是不知道的。hibernate3.0的大批量更新和刪除是不更新二級緩存的，但是據說3.1已經解決了這個問題。
這個限制相當的棘手，有時候hibernate做批量更新、刪除很慢，但是你卻不能自己寫jdbc來優化，很郁悶吧。
SessionFactory也提供了移除緩存的方法，你一定要自己寫一些JDBC的話，可以調用這些方法移除緩存，這些方法是：
void evict(Class persistentClass)
Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
Evict an entry from the second-level cache.
void evictCollection(String roleName)
Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
Evict an entry from the second-level cache.
void evictQueries()
Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
Evict any query result sets cached in the named query cache region.
不過我不建議這樣做，因為這樣很難維護。比如你現在用JDBC批量更新了某個表，有3個查詢緩存會用到這個表，用evictQueries(String cacheRegion)移除了3個查詢緩存，然後用evict(Class persistentClass)移除了class緩存，看上去好像完整了。不過哪天你添加了一個相關查詢緩存，可能會忘記更新這里的移除代碼。如果你的jdbc代碼到處都是，在你添加一個查詢緩存的時候，還知道其他什麼地方也要做相應的改動嗎？

----------------------------------------------------

總結：
不要想當然的以為緩存一定能提高性能，僅僅在你能夠駕馭它並且條件合適的情況下才是這樣的。hibernate的二級緩存限制還是比較多的，不方便用jdbc可能會大大的降低更新性能。在不了解原理的情況下亂用，可能會有1+N的問題。不當的使用還可能導致讀出臟數據。
如果受不了hibernate的諸多限制，那麼還是自己在應用程序的層面上做緩存吧。
在越高的層面上做緩存，效果就會越好。就好像盡管磁碟有緩存，資料庫還是要實現自己的緩存，盡管資料庫有緩存，咱們的應用程序還是要做緩存。因為底層的緩存它並不知道高層要用這些數據干什麼，只能做的比較通用，而高層可以有針對性的實現緩存，所以在更高的級別上做緩存，效果也要好些吧。