hibernate4二級緩存
⑴ hibernate二級緩存什麼時候用
Hibernate緩存何時使用和如何使用？
Hibernate緩存分為二級，第一級存放於session中稱為一級緩存，默認帶有且不能卸載。第二級是由sessionFactory控制的進程級緩存。是全局共享的緩存，凡是會調用二級緩存的查詢方法 都會從中受益。
1. 關於hibernate緩存的問題：
1.1. 基本的緩存原理
Hibernate緩存分為二級，
第一級存放於session中稱為一級緩存，默認帶有且不能卸載。
第二級是由sessionFactory控制的進程級緩存。是全局共享的緩存，凡是會調用二級緩存的查詢方法 都會從中受益。只有經正確的配置後二級緩存才會發揮作用。同時在進行條件查詢時必須使用相應的方法才能從緩存中獲取數據。比如 Query.iterate()方法、load、get方法等。必須注意的是session.find方法永遠是從資料庫中獲取數據，不會從二級緩存中獲 取數據，即便其中有其所需要的數據也是如此。
查詢時使用緩存的實現過程為：首先查詢一級緩存中是否具有需要的數據，如果沒有，查詢二級緩存，如果二級緩存中也沒有，此時再執行查詢資料庫的工作。要注意的是：此3種方式的查詢速度是依次降低的。
1.2. 存在的問題
1.2.1. 一級緩存的問題以及使用二級緩存的原因
因為Session的生命期往往很短，存在於Session內部的第一級最快緩存的生命期當然也很短，所以第一級緩存的命中率是很低的。其對系統性 能的改善也是很有限的。當然，這個Session內部緩存的主要作用是保持Session內部數據狀態同步。並非是hibernate為了大幅提高系統性 能所提供的。
為了提高使用hibernate的性能，除了常規的一些需要注意的方法比如：
使用延遲載入、迫切外連接、查詢過濾等以外，還需要配置hibernate的二級緩存。其對系統整體性能的改善往往具有立竿見影的效果！
（經過自己以前作項目的經驗，一般會有3~4倍的性能提高）
1.2.2. N+1次查詢的問題
1.2.2.1 什麼時候會遇到1+N的問題？
前提：Hibernate默認表與表的關聯方法是fetch="select"，不是fetch="join",這都是為了懶載入而准備的。
1）一對多(<set><list>) ，在1的這方，通過1條sql查找得到了1個對象，由於關聯的存在 ，那麼又需要將這個對象關聯的集合取出，所以合集數量是n還要發出n條sql，於是本來的1條sql查詢變成了1 +n條 。
2）多對一<many-to-one> ，在多的這方，通過1條sql查詢得到了n個對象，由於關聯的存在,也會將這n個對象對應的1 方的對象取出， 於是本來的1條sql查詢變成了1 +n條 。
3）iterator 查詢時,一定先去緩存中找（1條sql查集合,只查出ID），在沒命中時，會再按ID到庫中逐一查找， 產生1+n條SQL
1.2.2.2 怎麼解決1+N 問題？
1 ）lazy=true， hibernate3開始已經默認是lazy=true了；lazy=true時不會立刻查詢關聯對象，只有當需要關聯對象（訪問其屬性，非id欄位）時才會發生查詢動作。
2）使用二級緩存， 二級緩存的應用將不怕1+N 問題，因為即使第一次查詢很慢（未命中），以後查詢直接緩存命中也是很快的。剛好又利用了1+N 。
3) 當然你也可以設定fetch="join"，一次關聯表全查出來，但失去了懶載入的特性。
執行條件查詢時，iterate（）方法具有著名的 「n+1」次查詢的問題，也就是說在第一次查詢時iterate方法會執行滿足條件的查詢結果數再加一次（n+1）的查詢。但是此問題只存在於第一次查詢 時，在後面執行相同查詢時性能會得到極大的改善。此方法適合於查詢數據量較大的業務數據。
但是注意：當數據量特別大時（比如流水線數據等）需要針對此持久化對象配置其具體的緩存策略，比如設置其存在於緩存中的最大記錄數、緩存存在的時間等參數，以避免系統將大量的數據同時裝載入內存中引起內存資源的迅速耗盡，反而降低系統的性能！！！
1.3. 使用hibernate二級緩存的其他注意事項：
1.3.1. 關於數據的有效性
另外，hibernate會自行維護二級緩存中的數據，以保證緩存中的數據和資料庫中的真實數據的一致性！無論何時，當你調用save()、 update()或 saveOrUpdate()方法傳遞一個對象時，或使用load()、 get()、list()、iterate() 或scroll()方法獲得一個對象時, 該對象都將被加入到Session的內部緩存中。 當隨後flush()方法被調用時，對象的狀態會和資料庫取得同步。
也就是說刪除、更新、增加數據的時候，同時更新緩存。當然這也包括二級緩存！
只要是調用hibernate API執行資料庫相關的工作。hibernate都會為你自動保證 緩存數據的有效性！！
但是，如果你使用了JDBC繞過hibernate直接執行對資料庫的操作。此時，Hibernate不會/也不可能自行感知到資料庫被進行的變化改動，也就不能再保證緩存中數據的有效性！！
這也是所有的ORM產品共同具有的問題。幸運的是，Hibernate為我們暴露了Cache的清除方法，這給我們提供了一個手動保證數據有效性的機會！！
一級緩存，二級緩存都有相應的清除方法。
其中二級緩存提供的清除方法為：
按對象class清空緩存
按對象class和對象的主鍵id清空緩存
清空對象的集合中的緩存數據等。
1.3.2. 適合使用的情況
並非所有的情況都適合於使用二級緩存，需要根據具體情況來決定。同時可以針對某一個持久化對象配置其具體的緩存策略。
適合於使用二級緩存的情況：
1、數據不會被第三方修改；
一般情況下，會被hibernate以外修改的數據最好不要配置二級緩存，以免引起不一致的數據。但是如果此數據因為性能的原因需要被緩存，同時又 有可能被第3方比如SQL修改，也可以為其配置二級緩存。只是此時需要在sql執行修改後手動調用cache的清除方法。以保證數據的一致性
2、數據大小在可接收范圍之內；
如果數據表數據量特別巨大，此時不適合於二級緩存。原因是緩存的數據量過大可能會引起內存資源緊張，反而降低性能。
如果數據表數據量特別巨大，但是經常使用的往往只是較新的那部分數據。此時，也可為其配置二級緩存。但是必須單獨配置其持久化類的緩存策略，比如最大緩存數、緩存過期時間等，將這些參數降低至一個合理的范圍（太高會引起內存資源緊張，太低了緩存的意義不大）。
3、數據更新頻率低；
對於數據更新頻率過高的數據，頻繁同步緩存中數據的代價可能和 查詢緩存中的數據從中獲得的好處相當，壞處益處相抵消。此時緩存的意義也不大。
4、非關鍵數據（不是財務數據等）
財務數據等是非常重要的數據，絕對不允許出現或使用無效的數據，所以此時為了安全起見最好不要使用二級緩存。
因為此時 「正確性」的重要性遠遠大於 「高性能」的重要性。
2. 目前系統中使用hibernate緩存的建議
2.1. 目前情況
一般系統中有三種情況會繞開hibernate執行資料庫操作：
1、多個應用系統同時訪問一個資料庫
此種情況使用hibernate二級緩存會不可避免的造成數據不一致的問題，此時要進行詳細的設計。比如在設計上避免對同一數據表的同時的寫入操作，
使用資料庫各種級別的鎖定機制等。
2、動態表相關
所謂「動態表」是指在系統運行時根據用戶的操作系統自動建立的數據表。
比如「自定義表單」等屬於用戶自定義擴展開發性質的功能模塊，因為此時數據表是運行時建立的，所以不能進行hibernate的映射。因此對它的操作只能是繞開hibernate的直接資料庫JDBC操作。
如果此時動態表中的數據沒有設計緩存，就不存在數據不一致的問題。
如果此時自行設計了緩存機制，則調用自己的緩存同步方法即可。
3、使用sql對hibernate持久化對象表進行批量刪除時
此時執行批量刪除後，緩存中會存在已被刪除的數據。
分析：
當執行了第3條（sql批量刪除）後，後續的查詢只可能是以下三種方式：
a. session.find（）方法：
根據前面的總結，find方法不會查詢二級緩存的數據，而是直接查詢資料庫。
所以不存在數據有效性的問題。
b. 調用iterate方法執行條件查詢時：
根據iterate查詢方法的執行方式，其每次都會到資料庫中查詢滿足條件的id值，然後再根據此id 到緩存中獲取數據，當緩存中沒有此id的數據才會執行資料庫查詢；
如果此記錄已被sql直接刪除，則iterate在執行id查詢時不會將此id查詢出來。所以，即便緩存中有此條記錄也不會被客戶獲得，也就不存在不一致的情況。（此情況經過測試驗證）
c. 用get或load方法按id執行查詢：
客觀上此時會查詢得到已過期的數據。但是又因為系統中執行sql批量刪除一般是針對中間關聯數據表，對於中間關聯表的查詢一般都是採用條件查詢 ,按id來查詢某一條關聯關系的幾率很低,所以此問題也不存在!
如果某個值對象確實需要按id查詢一條關聯關系,同時又因為數據量大使用 了sql執行批量刪除。當滿足此兩個條件時,為了保證按id 的查詢得到正確的結果,可以使用手動清楚二級緩存中此對象的數據的方法!!(此種情況出現的可能性較小)
2.2. 建 議
1、建議不要使用sql直接執行數據持久化對象的數據的更新，但是可以執行 批量刪除。（系統中需要批量更新的地方也較少）
2、如果必須使用sql執行數據的更新，必須清空此對象的緩存數據。調用
SessionFactory.evict(class)
SessionFactory.evict(class,id)等方法。
3、在批量刪除數據量不大的時候可以直接採用hibernate的批量刪除，這樣就不存在繞開hibernate執行sql產生的緩存數據一致性的問題。
4、不推薦採用hibernate的批量刪除方法來刪除大批量的記錄數據。
原因是hibernate的批量刪除會執行1條查詢語句外加 滿足條件的n條刪除語句。而不是一次執行一條條件刪除語句！！
當待刪除的數據很多時會有很大的性能瓶頸！！！如果批量刪除數據量較大,比如超過50條,可以採用JDBC直接刪除。這樣作的好處是只執行一條sql刪除語句,性能會有很大的改善。同時，緩存數據同步的問題,可以採用 hibernate清除二級緩存中的相關數據的方法。
調 用
SessionFactory.evict(class) ;
SessionFactory.evict(class,id)等方法。
所以說，對於一般的應用系統開發而言（不涉及到集群，分布式數據同步問題等），因為只在中間關聯表執行批量刪除時調用了sql執行，同時中間關聯表 一般是執行條件查詢不太可能執行按id查詢。所以，此時可以直接執行sql刪除，甚至不需要調用緩存的清除方法。這樣做不會導致以後配置了二級緩存引起數 據有效性的問題。
退一步說，即使以後真的調用了按id查詢中間表對象的方法，也可以通過調用清除緩存的方法來解決。
3、具體的配置方法
根據我了解的很多hibernate的使用者在調用其相應方法時都迷信的相信「hibernate會自行為我們處理性能的問題」，或者 「hibernate 會自動為我們的所有操作調用緩存」,實際的情況是hibernate雖然為我們提供了很好的緩存機制和擴展緩存框架的支持，但是必須經過正確的調用其才有 可能發揮作用！！所以造成很多使用hibernate的系統的性能問題，實際上並不是hibernate不行或者不好，而是因為使用者沒有正確的了解其使 用方法造成的。相反，如果配置得當hibernate的性能表現會讓你有相當「驚喜的」發現。下面我講解具體的配置方法。
ibernate提供了二級緩存的介面：
net.sf.hibernate.cache.Provider,
同時提供了一個默認的 實現net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的實現 比如ehcache,jbosscache等。
具體的配置位置位於hibernate.cfg.xml文件中
<propertyname="hibernate.cache.use_query_cache">true</property>
<propertyname="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>
<hibernate-mapping>
<classname="com.sobey.sbm.model.entitySystem.vo.DataTypeVO"table="dcm_datatype">
<cacheusage="read-write"/>
<idname="id"column="TYPEID"type="java.lang.Long">
<generatorclass="sequence"/>
</id>
<propertyname="name"column="NAME"type="java.lang.String"/>
<propertyname="dbType"column="DBTYPE"type="java.lang.String"/>
</class>
</hibernate-mapping>
很多的hibernate使用者在 配置到 這一步 就以為 完事了，
注意：其實光這樣配，根本就沒有使用hibernate的二級緩存。同時因為他們在使用hibernate時大多時候是馬上關閉session，所 以，一級緩存也沒有起到任何作用。結果就是沒有使用任何緩存，所有的hibernate操作都是直接操作的資料庫！！性能可以想見。
正確的辦法是除了以上的配置外還應該配置每一個vo對象的具體緩存策略，在影射文件中配置。例如：
關鍵就是這個<cache usage="read-write"/>，其有幾個選擇read-only,read-write,transactional,等
然後在執行查詢時 注意了 ，如果是條件查詢，或者返回所有結果的查詢，此時session.find()方法 不會獲取緩存中的數據。只有調用query.iterate()方法時才會調緩存的數據。
同時 get 和 load方法 是都會查詢緩存中的數據
⑵ hibernate二級緩存設置問題
<property
name="hibernate.cache.use_second_level_cache">true</property>
<property
name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
前一句是打開二級緩存，後一句是啟用第三方緩存產品（可改變，上面eache是hibernate官方默認的第三方緩存產品）
緩存是否實用，要看你的需求，
如果你的系統，瀏覽的人數比較多，但是增刪的比較少，緩存的功勞非常大
如果你的系統即時性非常強，那麼緩存的命中率就比較低，同時更新數據時，hibernate需要額外提供資源維護緩存與數據的一致
⑶ 如何用redis做hibernate4的二級緩存，求實踐過的人解答
在向大家詳細介紹Hibernate二級緩存之前，首先讓大家了解下一級緩存，然後全面介紹Hibernate二級緩存。 Hibernate中提供了兩級Cache，第一級別的緩存是Session級別的緩存，它是屬於事務范圍的緩存。
⑷ 什麼是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二級緩存的問題
<property
name="hibernate.cache.use_second_level_cache">true</property>
<property
name="hibernate.cache.provider_class">org.hibernate.cache.ehcacheprovider</property>
前一句是打開二級緩存，後一句是啟用第三方緩存產品（可改變，上面eache是hibernate官方默認的第三方緩存產品）
緩存是否實用，要看你的需求，
如果你的系統，瀏覽的人數比較多，但是增刪的比較少，緩存的功勞非常大
如果你的系統即時性非常強，那麼緩存的命中率就比較低，同時更新數據時，hibernate需要額外提供資源維護緩存與數據的一致
⑹ Hibernate的一級緩存與二級緩存的區別
一級緩存就是Session級別的緩存，一個Session做了一個查詢操作，它會把這個操作的結果放在一級緩存中，如果短時間內這個session（一定要同一個session）又做了同一個操作，那麼hibernate直接從一級緩存中拿，而不會再去連資料庫，取數據。
二級緩存就是SessionFactory級別的緩存，顧名思義，就是查詢的時候會把查詢結果緩存到二級緩存中，如果同一個sessionFactory創建的某個session執行了相同的操作，hibernate就會從二級緩存中拿結果，而不會再去連接資料庫。
⑺ hibernate 二級緩存和查詢緩存有什麼區別
一級緩存為session級別的緩存，為hibernate內置緩存，你從資料庫load或get數據的時候會先去一級緩存上找。如果找到，則不會從資料庫中存，否則從資料庫中取。一級緩存會在session關閉時自動清除。
二級緩存為SessionFactory級別的緩存，要使用第三方二級緩存組件，不同session可以共享二級緩存中的數據！
查詢緩存就是hql或sql語句要相同，否則無法命中數據
⑻ Hibernate二級緩存的作用是什麼
使用緩存，是需要對應用系統進行性能優化而常採用的一種重要手段。合理地運用緩存，可以極大的提高應用系統的運行效率。
Hibernate中應用緩存：因為應用程序訪問資料庫，讀寫數據的代價非常高，而利用持久層的緩存可以減少應用程序與資料庫之間的交互，即把訪問過的數據保存到緩存中，應用程序再次訪問已經訪問過的數據，這些數據就可以從緩存中獲取，而不必再從資料庫中獲取。同時如果資料庫中的數據被修改或者刪除，那麼是、該數據所對應的緩存數據，也會被同步修改或刪除，進而保持緩存數據的一致性。
Hibernate的二級緩存由SessionFactory對象管理，是應用級別的緩存。它可以緩存整個應用的持久化對象，所以又稱為「SessionFactory緩存」。
hibernate二級緩存中的緩存對象可以被整個應用的Session對象共享，即使關閉當前Session對象，新建的Session對象仍可使用。使用Hibernate的二級緩存之後查詢數據，Session對象會首先在以及緩存中查找有無緩存數據被命中。如果沒有，則查找二級緩存。如果有，則直接返回所命中的數據；否則查詢資料庫。
⑼ hibernate一級緩存和二級緩存的區別
一級緩存：
就是Session級別的緩存。一個Session做了一個查詢操作，它會把這個操作的結果放在一級緩存中。
如果短時間內這個session（一定要同一個session）又做了同一個操作，那麼hibernate直接從一級緩存中拿，而不會再去連資料庫，取數據。
它是內置的事務范圍的緩存，不能被卸載。
二級緩存：
就是SessionFactory級別的緩存。顧名思義，就是查詢的時候會把查詢結果緩存到二級緩存中。
如果同一個sessionFactory創建的某個session執行了相同的操作，hibernate就會從二級緩存中拿結果，而不會再去連接資料庫。
這是可選的插件式的緩存，在默認情況下，SessionFactory不會啟用這個插件。
可以在每個類或每個集合的粒度上配置。緩存適配器用於把具體的緩存實現軟體與Hibernate集成。
嚴格意義上說，SessionFactory緩存分為兩類：內置緩存和外置緩存。我們通常意義上說的二級緩存是指外置緩存。
內置緩存與session級別緩存實現方式相似。前者是SessionFactory對象的一些集合屬性包含的數據，後者是指Session的一些集合屬性包含的數據
SessionFactory的內置緩存中存放了映射元數據和預定義SQL語句。
映射元數據是映射文件中數據的拷貝；
而預定義SQL語句是在Hibernate初始化階段根據映射元數據推導出來。
SessionFactory的內置緩存是只讀的，應用程序不能修改緩存中的映射元數據和預定義SQL語句，因此SessionFactory不需要進行內置緩存與映射文件的同步。
Hibernate的這兩級緩存都位於持久化層，存放的都是資料庫數據的拷貝。
緩存的兩個特性：
緩存的范圍
緩存的並發訪問策略
1、緩存的范圍
決定了緩存的生命周期以及可以被誰訪問。緩存的范圍分為三類。
事務范圍
進程范圍
集群范圍
註：
對大多數應用來說，應該慎重地考慮是否需要使用集群范圍的緩存，因為訪問的速度不一定會比直接訪問資料庫數據的速度快多少。
事務范圍的緩存是持久化層的第一級緩存，通常它是必需的；進程范圍或集群范圍的緩存是持久化層的第二級緩存，通常是可選的。
2、緩存的並發訪問策略
當多個並發的事務同時訪問持久化層的緩存的相同數據時，會引起並發問題，必須採用必要的事務隔離措施。
在進程范圍或集群范圍的緩存，即第二級緩存，會出現並發問題。
因此可以設定以下四種類型的並發訪問策略，每一種策略對應一種事務隔離級別。
事務型並發訪問策略是事務隔離級別最高，只讀型的隔離級別最低。事務隔離級別越高，並發性能就越低。
A 事務型：僅僅在受管理環境中適用。它提供了Repeatable Read事務隔離級別。
對於經常被讀但很少修改的數據，可以採用這種隔離類型，因為它可以防止臟讀和不可重復讀這類的並發問題。
B 讀寫型：提供了Read Committed事務隔離級別。僅僅在非集群的環境中適用。
對於經常被讀但很少修改的數據，可以採用這種隔離類型，因為它可以防止臟讀這類的並發問題。
C 非嚴格讀寫型：不保證緩存與資料庫中數據的一致性。
如果存在兩個事務同時訪問緩存中相同數據的可能，必須為該數據配置一個很短的數據過期時間，從而盡量避免臟讀。
對於極少被修改，並且允許偶爾臟讀的數據，可以採用這種並發訪問策略。
D 只讀型：對於從來不會修改的數據，如參考數據，可以使用這種並發訪問策略。
什麼樣的數據適合存放到第二級緩存中？
1、很少被修改的數據
2、不是很重要的數據，允許出現偶爾並發的數據
3、不會被並發訪問的數據
4、參考數據
不適合存放到第二級緩存的數據？
1、經常被修改的數據
2、財務數據，絕對不允許出現並發
3、與其他應用共享的數據。
Hibernate的二級緩存策略的一般過程如下：
1) 條件查詢的時候，總是發出一條select * from table_name where …. （選擇所有欄位）這樣的SQL語句查詢資料庫，一次獲得所有的數據對象。
2) 把獲得的所有數據對象根據ID放入到第二級緩存中。
3) 當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那麼從二級緩存中查；查不到，再查詢資料庫，把結果按照ID放入到緩存。
4) 刪除、更新、增加數據的時候，同時更新緩存。
註：
Hibernate的二級緩存策略，是針對於ID查詢的緩存策略，對於條件查詢則毫無作用。為此，Hibernate提供了針對條件查詢的Query緩存。
Query緩存策略的過程如下：
1) Hibernate首先根據這些信息組成一個Query Key，Query Key包括條件查詢的請求一般信息：SQL, SQL需要的參數，記錄范圍（起始位置rowStart，最大記錄個數maxRows)，等。
2) Hibernate根據這個Query Key到Query緩存中查找對應的結果列表。如果存在，那麼返回這個結果列表；如果不存在，查詢資料庫，獲取結果列表，把整個結果列表根據Query Key放入到Query緩存中。
3) Query Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query Key都要從緩存中清空。
⑽ hibernate緩存機制的二級緩存
Hibernate提供了兩級緩存，第一級是Session的緩存。由於Session對象的生命周期通常對應一個資料庫事務或者一個應用事務，因此它的緩存是事務范圍的緩存。第一級緩存是必需的，不允許而且事實上也無法卸除。在第一級緩存中，持久化類的每個實例都具有唯一的OID。
第二級緩存是一個可插拔的的緩存插件，它是由SessionFactory負責管理。由於SessionFactory對象的生命周期和應用程序的整個過程對應，因此第二級緩存是進程范圍或者集群范圍的緩存。這個緩存中存放的對象的鬆散數據。第二級對象有可能出現並發問題，因此需要採用適當的並發訪問策略，該策略為被緩存的數據提供了事務隔離級別。緩存適配器用於把具體的緩存實現軟體與Hibernate集成。第二級緩存是可選的，可以在每個類或每個集合的粒度上配置第二級緩存。 適合存放到第二級緩存中的數據
1 很少被修改的數據
2 不是很重要的數據，允許出現偶爾並發的數據
3 不會被並發訪問的數據
4 參考數據
不適合存放到第二級緩存的數據
1 經常被修改的數據
2 財務數據，絕對不允許出現並發
3 與其他應用共享的數據。 1) 條件查詢的時候，總是發出一條select * from table_name where …. （選擇所有欄位）這樣的SQL語句查詢資料庫，一次獲得所有的數據對象。
2) 把獲得的所有數據對象根據ID放入到第二級緩存中。
3) 當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那麼從二級緩存中查；查不到，再查詢資料庫，把結果按照ID放入到緩存。
4) 刪除、更新、增加數據的時候，同時更新緩存。
Hibernate的二級緩存策略，是針對於ID查詢的緩存策略，對於條件查詢則毫無作用。為此，Hibernate提供了針對條件查詢的Query緩存。
Hibernate的Query緩存策略的過程如下：
1) Hibernate首先根據這些信息組成一個Query Key，Query Key包括條件查詢的請求一般信息：SQL, SQL需要的參數，記錄范圍（起始位置rowStart，最大記錄個數maxRows)，等。
2) Hibernate根據這個Query Key到Query緩存中查找對應的結果列表。如果存在，那麼返回這個結果列表；如果不存在，查詢資料庫，獲取結果列表，把整個結果列表根據Query Key放入到Query緩存中。
3) Query Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query Key都要從緩存中清空。