Hibernate緩存何時(shí)使用和如何使用
1. 關(guān)于hibernate緩存的問(wèn)題：
1.1. 基本的緩存原理
Hibernate緩存分為二級(jí)，
第一級(jí)存放于session中稱(chēng)為一級(jí)緩存，默認(rèn)帶有且不能卸載。
第二級(jí)是由sessionFactory控制的進(jìn)程級(jí)緩存。是全局共享的緩存，凡是會(huì)調(diào)用二級(jí)緩存的查詢(xún)方法 都會(huì)從中受益。只有經(jīng)正確的配置后二級(jí)緩存才會(huì)發(fā)揮作用。同時(shí)在進(jìn)行條件查詢(xún)時(shí)必須使用相應(yīng)的方法才能從緩存中獲取數(shù)據(jù)。比如Query.iterate()方法、load、get方法等。必須注意的是session.find方法永遠(yuǎn)是從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)，不會(huì)從二級(jí)緩存中獲取數(shù)據(jù)，即便其中有其所需要的數(shù)據(jù)也是如此。
查詢(xún)時(shí)使用緩存的實(shí)現(xiàn)過(guò)程為：首先查詢(xún)一級(jí)緩存中是否具有需要的數(shù)據(jù)，如果沒(méi)有，查詢(xún)二級(jí)緩存，如果二級(jí)緩存中也沒(méi)有，此時(shí)再執(zhí)行查詢(xún)數(shù)據(jù)庫(kù)的工作。要注意的是：此3種方式的查詢(xún)速度是依次降低的。
1.2. 存在的問(wèn)題
1.2.1. 一級(jí)緩存的問(wèn)題以及使用二級(jí)緩存的原因
因?yàn)镾ession的生命期往往很短，存在于Session內(nèi)部的第一級(jí)最快緩存的生命期當(dāng)然也很短，所以第一級(jí)緩存的命中率是很低的。其對(duì)系統(tǒng)性能的改善也是很有限的。當(dāng)然，這個(gè)Session內(nèi)部緩存的主要作用是保持Session內(nèi)部數(shù)據(jù)狀態(tài)同步。并非是hibernate為了大幅提高系統(tǒng)性能所提供的。
為了提高使用hibernate的性能，除了常規(guī)的一些需要注意的方法比如：
使用延遲加載、迫切外連接、查詢(xún)過(guò)濾等以外，還需要配置hibernate的二級(jí)緩存。其對(duì)系統(tǒng)整體性能的改善往往具有立竿見(jiàn)影的效果！
（經(jīng)過(guò)自己以前作項(xiàng)目的經(jīng)驗(yàn)，一般會(huì)有3~4倍的性能提高）
1.2.2. N+1次查詢(xún)的問(wèn)題
1.2.2.1 什么時(shí)候會(huì)遇到1+N的問(wèn)題？
前提：Hibernate默認(rèn)表與表的關(guān)聯(lián)方法是fetch="select"，不是fetch="join",這都是為了懶加載而準(zhǔn)備的。
1）一對(duì)多(<set><list>) ，在1的這方，通過(guò)1條sql查找得到了1個(gè)對(duì)象，由于關(guān)聯(lián)的存在 ，那么又需要將這個(gè)對(duì)象關(guān)聯(lián)的集合取出，所以合集數(shù)量是n還要發(fā)出n條sql，于是本來(lái)的1條sql查詢(xún)變成了1 +n條 。
2）多對(duì)一<many-to-one> ，在多的這方，通過(guò)1條sql查詢(xún)得到了n個(gè)對(duì)象，由于關(guān)聯(lián)的存在,也會(huì)將這n個(gè)對(duì)象對(duì)應(yīng)的1 方的對(duì)象取出， 于是本來(lái)的1條sql查詢(xún)變成了1 +n條 。
3）iterator 查詢(xún)時(shí),一定先去緩存中找（1條sql查集合,只查出ID），在沒(méi)命中時(shí)，會(huì)再按ID到庫(kù)中逐一查找， 產(chǎn)生1+n條SQL
1.2.2.2 怎么解決1+N 問(wèn)題？
1 ）lazy=true， hibernate3開(kāi)始已經(jīng)默認(rèn)是lazy=true了；lazy=true時(shí)不會(huì)立刻查詢(xún)關(guān)聯(lián)對(duì)象，只有當(dāng)需要關(guān)聯(lián)對(duì)象（訪(fǎng)問(wèn)其屬性，非id字段）時(shí)才會(huì)發(fā)生查詢(xún)動(dòng)作。
2）使用二級(jí)緩存， 二級(jí)緩存的應(yīng)用將不怕1+N 問(wèn)題，因?yàn)榧词沟谝淮尾樵?xún)很慢（未命中），以后查詢(xún)直接緩存命中也是很快的。剛好又利用了1+N 。
3) 當(dāng)然你也可以設(shè)定fetch="join"，一次關(guān)聯(lián)表全查出來(lái)，但失去了懶加載的特性。
執(zhí)行條件查詢(xún)時(shí)，iterate（）方法具有著名的 “n+1”次查詢(xún)的問(wèn)題，也就是說(shuō)在第一次查詢(xún)時(shí)iterate方法會(huì)執(zhí)行滿(mǎn)足條件的查詢(xún)結(jié)果數(shù)再加一次（n+1）的查詢(xún)。但是此問(wèn)題只存在于第一次查詢(xún)時(shí)，在后面執(zhí)行相同查詢(xún)時(shí)性能會(huì)得到極大的改善。此方法適合于查詢(xún)數(shù)據(jù)量較大的業(yè)務(wù)數(shù)據(jù)。
但是注意：當(dāng)數(shù)據(jù)量特別大時(shí)（比如流水線(xiàn)數(shù)據(jù)等）需要針對(duì)此持久化對(duì)象配置其具體的緩存策略，比如設(shè)置其存在于緩存中的最大記錄數(shù)、緩存存在的時(shí)間等參數(shù)，以避免系統(tǒng)將大量的數(shù)據(jù)同時(shí)裝載入內(nèi)存中引起內(nèi)存資源的迅速耗盡，反而降低系統(tǒng)的性能！！！
1.3. 使用hibernate二級(jí)緩存的其他注意事項(xiàng)：
1.3.1. 關(guān)于數(shù)據(jù)的有效性
另外，hibernate會(huì)自行維護(hù)二級(jí)緩存中的數(shù)據(jù)，以保證緩存中的數(shù)據(jù)和數(shù)據(jù)庫(kù)中的真實(shí)數(shù)據(jù)的一致性！無(wú)論何時(shí)，當(dāng)你調(diào)用save()、update()或 saveOrUpdate()方法傳遞一個(gè)對(duì)象時(shí)，或使用load()、 get()、list()、iterate() 或scroll()方法獲得一個(gè)對(duì)象時(shí), 該對(duì)象都將被加入到Session的內(nèi)部緩存中。 當(dāng)隨后flush()方法被調(diào)用時(shí)，對(duì)象的狀態(tài)會(huì)和數(shù)據(jù)庫(kù)取得同步。
也就是說(shuō)刪除、更新、增加數(shù)據(jù)的時(shí)候，同時(shí)更新緩存。當(dāng)然這也包括二級(jí)緩存！
只要是調(diào)用hibernate API執(zhí)行數(shù)據(jù)庫(kù)相關(guān)的工作。hibernate都會(huì)為你自動(dòng)保證 緩存數(shù)據(jù)的有效性！！
但是，如果你使用了JDBC繞過(guò)hibernate直接執(zhí)行對(duì)數(shù)據(jù)庫(kù)的操作。此時(shí)，Hibernate不會(huì)/也不可能自行感知到數(shù)據(jù)庫(kù)被進(jìn)行的變化改動(dòng)，也就不能再保證緩存中數(shù)據(jù)的有效性！！
這也是所有的ORM產(chǎn)品共同具有的問(wèn)題。幸運(yùn)的是，Hibernate為我們暴露了Cache的清除方法，這給我們提供了一個(gè)手動(dòng)保證數(shù)據(jù)有效性的機(jī)會(huì)！！
一級(jí)緩存，二級(jí)緩存都有相應(yīng)的清除方法。
其中二級(jí)緩存提供的清除方法為：
按對(duì)象class清空緩存
按對(duì)象class和對(duì)象的主鍵id清空緩存
清空對(duì)象的集合中的緩存數(shù)據(jù)等。
1.3.2. 適合使用的情況
并非所有的情況都適合于使用二級(jí)緩存，需要根據(jù)具體情況來(lái)決定。同時(shí)可以針對(duì)某一個(gè)持久化對(duì)象配置其具體的緩存策略。
適合于使用二級(jí)緩存的情況：
1、數(shù)據(jù)不會(huì)被第三方修改；
一般情況下，會(huì)被hibernate以外修改的數(shù)據(jù)最好不要配置二級(jí)緩存，以免引起不一致的數(shù)據(jù)。但是如果此數(shù)據(jù)因?yàn)樾阅艿脑蛐枰痪彺妫瑫r(shí)又有可能被第3方比如SQL修改，也可以為其配置二級(jí)緩存。只是此時(shí)需要在sql執(zhí)行修改后手動(dòng)調(diào)用cache的清除方法。以保證數(shù)據(jù)的一致性
2、數(shù)據(jù)大小在可接收范圍之內(nèi)；
如果數(shù)據(jù)表數(shù)據(jù)量特別巨大，此時(shí)不適合于二級(jí)緩存。原因是緩存的數(shù)據(jù)量過(guò)大可能會(huì)引起內(nèi)存資源緊張，反而降低性能。
如果數(shù)據(jù)表數(shù)據(jù)量特別巨大，但是經(jīng)常使用的往往只是較新的那部分?jǐn)?shù)據(jù)。此時(shí)，也可為其配置二級(jí)緩存。但是必須單獨(dú)配置其持久化類(lèi)的緩存策略，比如最大緩存數(shù)、緩存過(guò)期時(shí)間等，將這些參數(shù)降低至一個(gè)合理的范圍（太高會(huì)引起內(nèi)存資源緊張，太低了緩存的意義不大）。
3、數(shù)據(jù)更新頻率低；
對(duì)于數(shù)據(jù)更新頻率過(guò)高的數(shù)據(jù)，頻繁同步緩存中數(shù)據(jù)的代價(jià)可能和 查詢(xún)緩存中的數(shù)據(jù)從中獲得的好處相當(dāng)，壞處益處相抵消。此時(shí)緩存的意義也不大。
4、非關(guān)鍵數(shù)據(jù)（不是財(cái)務(wù)數(shù)據(jù)等）
財(cái)務(wù)數(shù)據(jù)等是非常重要的數(shù)據(jù)，絕對(duì)不允許出現(xiàn)或使用無(wú)效的數(shù)據(jù)，所以此時(shí)為了安全起見(jiàn)最好不要使用二級(jí)緩存。
因?yàn)榇藭r(shí) “正確性”的重要性遠(yuǎn)遠(yuǎn)大于 “高性能”的重要性。
2. 目前系統(tǒng)中使用hibernate緩存的建議
2.1. 目前情況
一般系統(tǒng)中有三種情況會(huì)繞開(kāi)hibernate執(zhí)行數(shù)據(jù)庫(kù)操作：
1、多個(gè)應(yīng)用系統(tǒng)同時(shí)訪(fǎng)問(wèn)一個(gè)數(shù)據(jù)庫(kù)
此種情況使用hibernate二級(jí)緩存會(huì)不可避免的造成數(shù)據(jù)不一致的問(wèn)題，此時(shí)要進(jìn)行詳細(xì)的設(shè)計(jì)。比如在設(shè)計(jì)上避免對(duì)同一數(shù)據(jù)表的同時(shí)的寫(xiě)入操作，
使用數(shù)據(jù)庫(kù)各種級(jí)別的鎖定機(jī)制等。
2、動(dòng)態(tài)表相關(guān)
所謂“動(dòng)態(tài)表”是指在系統(tǒng)運(yùn)行時(shí)根據(jù)用戶(hù)的操作系統(tǒng)自動(dòng)建立的數(shù)據(jù)表。
比如“自定義表單”等屬于用戶(hù)自定義擴(kuò)展開(kāi)發(fā)性質(zhì)的功能模塊，因?yàn)榇藭r(shí)數(shù)據(jù)表是運(yùn)行時(shí)建立的，所以不能進(jìn)行hibernate的映射。因此對(duì)它的操作只能是繞開(kāi)hibernate的直接數(shù)據(jù)庫(kù)JDBC操作。
如果此時(shí)動(dòng)態(tài)表中的數(shù)據(jù)沒(méi)有設(shè)計(jì)緩存，就不存在數(shù)據(jù)不一致的問(wèn)題。
如果此時(shí)自行設(shè)計(jì)了緩存機(jī)制，則調(diào)用自己的緩存同步方法即可。
3、使用sql對(duì)hibernate持久化對(duì)象表進(jìn)行批量刪除時(shí)
此時(shí)執(zhí)行批量刪除后，緩存中會(huì)存在已被刪除的數(shù)據(jù)。
分析：
當(dāng)執(zhí)行了第3條（sql批量刪除）后，后續(xù)的查詢(xún)只可能是以下三種方式：
a. session.find（）方法：
根據(jù)前面的總結(jié)，find方法不會(huì)查詢(xún)二級(jí)緩存的數(shù)據(jù)，而是直接查詢(xún)數(shù)據(jù)庫(kù)。
所以不存在數(shù)據(jù)有效性的問(wèn)題。
b. 調(diào)用iterate方法執(zhí)行條件查詢(xún)時(shí)：
根據(jù)iterate查詢(xún)方法的執(zhí)行方式，其每次都會(huì)到數(shù)據(jù)庫(kù)中查詢(xún)滿(mǎn)足條件的id值，然后再根據(jù)此id 到緩存中獲取數(shù)據(jù)，當(dāng)緩存中沒(méi)有此id的數(shù)據(jù)才會(huì)執(zhí)行數(shù)據(jù)庫(kù)查詢(xún)；
如果此記錄已被sql直接刪除，則iterate在執(zhí)行id查詢(xún)時(shí)不會(huì)將此id查詢(xún)出來(lái)。所以，即便緩存中有此條記錄也不會(huì)被客戶(hù)獲得，也就不存在不一致的情況。（此情況經(jīng)過(guò)測(cè)試驗(yàn)證）
c. 用get或load方法按id執(zhí)行查詢(xún)：
客觀上此時(shí)會(huì)查詢(xún)得到已過(guò)期的數(shù)據(jù)。但是又因?yàn)橄到y(tǒng)中執(zhí)行sql批量刪除一般是針對(duì)中間關(guān)聯(lián)數(shù)據(jù)表，對(duì)于中間關(guān)聯(lián)表的查詢(xún)一般都是采用條件查詢(xún) ,按id來(lái)查詢(xún)某一條關(guān)聯(lián)關(guān)系的幾率很低,所以此問(wèn)題也不存在!
如果某個(gè)值對(duì)象確實(shí)需要按id查詢(xún)一條關(guān)聯(lián)關(guān)系,同時(shí)又因?yàn)閿?shù)據(jù)量大使用 了sql執(zhí)行批量刪除。當(dāng)滿(mǎn)足此兩個(gè)條件時(shí),為了保證按id 的查詢(xún)得到正確的結(jié)果,可以使用手動(dòng)清楚二級(jí)緩存中此對(duì)象的數(shù)據(jù)的方法!!(此種情況出現(xiàn)的可能性較小)
2.2. 建 議
1、建議不要使用sql直接執(zhí)行數(shù)據(jù)持久化對(duì)象的數(shù)據(jù)的更新，但是可以執(zhí)行 批量刪除。（系統(tǒng)中需要批量更新的地方也較少）
2、如果必須使用sql執(zhí)行數(shù)據(jù)的更新，必須清空此對(duì)象的緩存數(shù)據(jù)。調(diào)用
SessionFactory.evict(class)
SessionFactory.evict(class,id)等方法。
3、在批量刪除數(shù)據(jù)量不大的時(shí)候可以直接采用hibernate的批量刪除，這樣就不存在繞開(kāi)hibernate執(zhí)行sql產(chǎn)生的緩存數(shù)據(jù)一致性的問(wèn)題。
4、不推薦采用hibernate的批量刪除方法來(lái)刪除大批量的記錄數(shù)據(jù)。
原因是hibernate的批量刪除會(huì)執(zhí)行1條查詢(xún)語(yǔ)句外加 滿(mǎn)足條件的n條刪除語(yǔ)句。而不是一次執(zhí)行一條條件刪除語(yǔ)句！！
當(dāng)待刪除的數(shù)據(jù)很多時(shí)會(huì)有很大的性能瓶頸！！！如果批量刪除數(shù)據(jù)量較大,比如超過(guò)50條,可以采用JDBC直接刪除。這樣作的好處是只執(zhí)行一條sql刪除語(yǔ)句,性能會(huì)有很大的改善。同時(shí)，緩存數(shù)據(jù)同步的問(wèn)題,可以采用 hibernate清除二級(jí)緩存中的相關(guān)數(shù)據(jù)的方法。
調(diào) 用
SessionFactory.evict(class) ;
SessionFactory.evict(class,id)等方法。
所以說(shuō)，對(duì)于一般的應(yīng)用系統(tǒng)開(kāi)發(fā)而言（不涉及到集群，分布式數(shù)據(jù)同步問(wèn)題等），因?yàn)橹辉谥虚g關(guān)聯(lián)表執(zhí)行批量刪除時(shí)調(diào)用了sql執(zhí)行，同時(shí)中間關(guān)聯(lián)表一般是執(zhí)行條件查詢(xún)不太可能執(zhí)行按id查詢(xún)。所以，此時(shí)可以直接執(zhí)行sql刪除，甚至不需要調(diào)用緩存的清除方法。這樣做不會(huì)導(dǎo)致以后配置了二級(jí)緩存引起數(shù)據(jù)有效性的問(wèn)題。
退一步說(shuō)，即使以后真的調(diào)用了按id查詢(xún)中間表對(duì)象的方法，也可以通過(guò)調(diào)用清除緩存的方法來(lái)解決。
3、具體的配置方法
根據(jù)我了解的很多hibernate的使用者在調(diào)用其相應(yīng)方法時(shí)都迷信的相信“hibernate會(huì)自行為我們處理性能的問(wèn)題”，或者“hibernate 會(huì)自動(dòng)為我們的所有操作調(diào)用緩存”,實(shí)際的情況是hibernate雖然為我們提供了很好的緩存機(jī)制和擴(kuò)展緩存框架的支持，但是必須經(jīng)過(guò)正確的調(diào)用其才有可能發(fā)揮作用！！所以造成很多使用hibernate的系統(tǒng)的性能問(wèn)題，實(shí)際上并不是hibernate不行或者不好，而是因?yàn)槭褂谜邲](méi)有正確的了解其使用方法造成的。相反，如果配置得當(dāng)hibernate的性能表現(xiàn)會(huì)讓你有相當(dāng)“驚喜的”發(fā)現(xiàn)。下面我講解具體的配置方法。
ibernate提供了二級(jí)緩存的接口：
net.sf.hibernate.cache.Provider,
同時(shí)提供了一個(gè)默認(rèn)的 實(shí)現(xiàn)net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的實(shí)現(xiàn) 比如ehcache,jbosscache等。
具體的配置位置位于hibernate.cfg.xml文件中
- <property name="hibernate.cache.use_query_cache">true</property>
- <property name="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>
很多的hibernate使用者在 配置到 這一步 就以為 完事了，
注意：其實(shí)光這樣配，根本就沒(méi)有使用hibernate的二級(jí)緩存。同時(shí)因?yàn)樗麄冊(cè)谑褂胔ibernate時(shí)大多時(shí)候是馬上關(guān)閉session，所以，一級(jí)緩存也沒(méi)有起到任何作用。結(jié)果就是沒(méi)有使用任何緩存，所有的hibernate操作都是直接操作的數(shù)據(jù)庫(kù)！！性能可以想見(jiàn)。
正確的辦法是除了以上的配置外還應(yīng)該配置每一個(gè)vo對(duì)象的具體緩存策略，在影射文件中配置。例如：
- <hibernate-mapping>
- <class name="com.sobey.sbm.model.entitySystem.vo.DataTypeVO" table="dcm_datatype">
- <cache usage="read-write"/>
- <id name="id" column="TYPEID" type="java.lang.Long">
- <generator class="sequence"/>
- </id>
- <property name="name" column="NAME" type="java.lang.String"/>
- <property name="dbType" column="DBTYPE" type="java.lang.String"/>
- </class>
- </hibernate-mapping>
關(guān)鍵就是這個(gè)<cache usage="read-write"/>，其有幾個(gè)選擇read-only,read-write,transactional,等
然后在執(zhí)行查詢(xún)時(shí) 注意了 ，如果是條件查詢(xún)，或者返回所有結(jié)果的查詢(xún)，此時(shí)session.find()方法 不會(huì)獲取緩存中的數(shù)據(jù)。只有調(diào)用query.iterate()方法時(shí)才會(huì)調(diào)緩存的數(shù)據(jù)。
同時(shí) get 和 load方法 是都會(huì)查詢(xún)緩存中的數(shù)據(jù)
對(duì)于不同的緩存框架具體的配置方法會(huì)有不同，但是大體是以上的配置（另外，對(duì)于支持事務(wù)型，以及支持集群的環(huán)境的配置我會(huì)爭(zhēng)取在后續(xù)的文章中中 發(fā)表出來(lái)）
參考資料：
http://hi.baidu.com/zxmsdyz/blog/item/3dbf43d1f3236b309b50270b.html
http://elf8848.iteye.com/blog/342691
http://blog.csdn.net/dongzi87/article/details/6621497
http://blog.csdn.net/dengqf/article/details/2235332
http://log-cd.iteye.com/blog/355097
【編輯推薦】
