hibernate緩存和查詢優(yōu)化和事務(wù)隔離機制

1、一級緩存的管理 應(yīng)用程序調(diào)用Session的save()、update()、saveOrUpdate()、get()或load()，以及調(diào)用查詢接口的 iterate()， list()、時，如果在Session緩存中還不存在相應(yīng)的對象，Hibernate就會把該對象加入到第一級緩存中。 可以通過close/clear/evict清空緩存作用 因為Session的生命期往往很短，存在于Session內(nèi)部的第一級最快緩存的生命期當(dāng)然也很短，所以第一級緩存的命中率是很低的。其對系統(tǒng)性能的改善也是很有限的。Session內(nèi)部緩存的主要作用是保持Session內(nèi)部數(shù)據(jù)狀態(tài)同步。開啟： true org

2、.hibernate.cache.EhCacheProvider如何使用： 類定義前面：cache，指該類的對象都會放入二級緩存。Cache(usage=CacheConcurrencyStrategy.READ_WRITE) /放入二級緩存中也可以被修改。一般用它。什么內(nèi)容時候放入二級緩存：經(jīng)常被訪問、改動不頻繁、數(shù)量有限。load都會使用二級緩存。 注意：load和get的主要區(qū)別回顧： 搜索不到符合條件的記錄，get返回一個null，load會拋出一個ObjectNotFountdException get會使用二級級緩存。Load會使用二級緩存 Load有懶加載。Get直接獲得數(shù)據(jù)對象

3、iterate也會使用二級緩存。list默認(rèn)會往二級緩存中存放數(shù)據(jù)，即通過list查出的結(jié)果會放入二級緩存。但是list本身查詢時不會使用二級緩存。緩 存 插 件支 持 只讀支持非嚴(yán)格讀寫支 持 讀 寫支 持 事 務(wù)EhCache是是是OSCache是是是SwarmCache是是JBossCache是是查詢緩存只對查詢緩存只對query.list()query.list()起作用起作用查詢緩存依賴于二級緩存，因此一定要打開二級緩存。查詢緩存依賴于二級緩存，因此一定要打開二級緩存。查詢緩存實現(xiàn)機制：以查詢語句為查詢緩存實現(xiàn)機制：以查詢語句為keykey，查到的對象的，查到的對象的idid為為va

4、luevalue查詢緩存的配置和使用：查詢緩存的配置和使用： 開啟二級緩存 true /默認(rèn)是fasle 在程序中必須手動啟用查詢緩存，如：query.setCacheable(true); 緩存滿了后，將內(nèi)存中哪個對象清掉。 LRU Least Recently Used 最近最少被使用的。每個緩存對象都記錄一個最后使用時間。 LFU Least Frequently Used 最近使用頻率最少。 FIFO First In First Out在一對多/多對一中，經(jīng)常出現(xiàn)1+N問題。 在1方，查找得到了n個對象， 那么又需要將n個對象關(guān)聯(lián)的集合取出，于是本來的一條sql查詢變成了n+1條。解

5、決方案： 懶加載 OneToMany(mappedBy=“banji”,fetch=FetchType.LAZY) (默認(rèn)即為此)二級緩存 在對象更新，刪除，添加相對于查詢要少得多時， 二級緩存的應(yīng)用將不怕n+1問題，因為即使第一次查詢很慢，之后直接緩存命中也是很快的，剛好又利用了n+1。List僅僅會填充二級緩存，卻不能利用二級緩存。iterator可以讀二級緩存，對于一條查詢語句，它會先從數(shù)據(jù)庫中找出所有符合條件的記錄的ID，再通過ID去緩存找，對于緩存中沒有的記錄，再構(gòu)造語句從數(shù)據(jù)庫中查出。在緩存中沒有命中的話，效率很低。最好的辦法就是： 在應(yīng)用啟動時和數(shù)據(jù)被修改時使用list。平時則使

6、用iterator。（只針對修改不頻繁的數(shù)據(jù)?。┮话汩_始開發(fā)并不使用緩存機制。根據(jù)需求如果不能滿足性能要求，才增加緩存。 二級緩存：緩存數(shù)據(jù)內(nèi)容變化頻率不高的內(nèi)容。 查詢緩存很多系統(tǒng)經(jīng)常在應(yīng)用層增加緩存： OSCACHE在J2EE中的應(yīng)用建議： 大批量數(shù)據(jù)的處理不要使用hibernate,優(yōu)先考慮JDBC的批量處理。（一般使用JDBC） 如果對性能要求極高，可以考慮PL/SQL數(shù)據(jù)量巨大，性能要求高，hibernate由于在ORM映射中對系統(tǒng)資源消耗也比較高，所以不適合。Hibernate適合：邏輯復(fù)雜，數(shù)據(jù)量不大。sessionFactory的創(chuàng)建非常消耗資源，整個應(yīng)用一般只要一個。將所有的

7、集合屬性配置設(shè)置為懶加載。 Hibernate2.x默認(rèn)是false, hibernate3.x默認(rèn)是true在定義關(guān)聯(lián)關(guān)系時，集合首選Set，如果集合中的實體存在重復(fù)，則選擇List，數(shù)組性能最差。在一對多的雙向關(guān)聯(lián)中，一般將集合的inverse設(shè)置為true，讓集合的對方維護關(guān)聯(lián)關(guān)系。HQL子句本身大小寫無關(guān)，但是其中出現(xiàn)的類名和屬性名必須注意大小寫區(qū)分。對大數(shù)據(jù)量查詢時，慎用list() 返回查詢結(jié)果在性能瓶頸的地方使用JDBC。使用雙向關(guān)聯(lián)。在大型應(yīng)用中，幾乎所有的關(guān)聯(lián)必須在查詢中可以雙向?qū)Ш?。事?wù)基本概念 ACID即是atomicity（原子性），consistency（一致性），i

8、solation（隔離性）和durability（執(zhí)久性）的首字母的縮寫 原子性表示一個事務(wù)內(nèi)的所有操作是一個整體，要 么全部成功，要么全失??； 一致性表示一個事務(wù)內(nèi)有一個操作失敗時，所有的更改過的數(shù)據(jù)都必須回滾到修改前的狀態(tài)； 隔離性：事務(wù)查看數(shù)據(jù)時數(shù)據(jù)所處的狀態(tài)，要么是另一并發(fā)事務(wù)修改它之前的狀態(tài)，要么是另一事務(wù)修改它之后的狀態(tài)，事務(wù)不會查看中間狀態(tài)的數(shù)據(jù)。 持久性事務(wù)完成之后，它對于系統(tǒng)的影響是永久性的。事務(wù)隔離級別從低到高： 讀取未提交（讀取未提交（Read Uncommitted)Read Uncommitted) 讀取已提交讀取已提交(Read Committed)(Read Co

9、mmitted) 可重復(fù)讀（Repeatable Read) 序列化（serializable)讀取未提交（讀取未提交（Read Uncommitted)Read Uncommitted) 這是最低的事務(wù)隔離級別，讀事務(wù)不會阻塞讀事務(wù)和寫事務(wù)，這是最低的事務(wù)隔離級別，讀事務(wù)不會阻塞讀事務(wù)和寫事務(wù)，寫事務(wù)也不會阻塞讀事務(wù)，但是會阻塞寫事務(wù)。寫事務(wù)也不會阻塞讀事務(wù)，但是會阻塞寫事務(wù)。 寫事務(wù)不阻塞讀事務(wù)，可以讀取未提交的數(shù)據(jù)，容易造成臟讀寫事務(wù)不阻塞讀事務(wù)，可以讀取未提交的數(shù)據(jù)，容易造成臟讀 臟讀現(xiàn)象：臟讀現(xiàn)象： 臟讀解決方案：臟讀解決方案： 如果在第一個事務(wù)提交前，任何其他事務(wù)不可讀取其修改過的

10、值，則可 以避免該問題。1.Mary的原工資為1000, 財務(wù)人員將Mary的工資改為了8000(但未提交事務(wù)) 2.Mary讀取自己的工資 ,發(fā)現(xiàn)自己的工資變?yōu)榱?000，歡天喜地！3.而財務(wù)發(fā)現(xiàn)操作有誤，回滾了事務(wù),Mary的工資又變?yōu)榱?000 像這樣,Mary記取的工資數(shù)8000是一個臟數(shù)據(jù)。讀取已提交讀取已提交(Read Committed)(Read Committed) 寫事務(wù)就會阻塞讀事務(wù)和寫事務(wù)寫事務(wù)就會阻塞讀事務(wù)和寫事務(wù)，但是讀事務(wù)不會阻塞讀但是讀事務(wù)不會阻塞讀事務(wù)和寫事務(wù)。讀事務(wù)不阻塞寫事務(wù)，但是有可能造成不事務(wù)和寫事務(wù)。讀事務(wù)不阻塞寫事務(wù)，但是有可能造成不可重復(fù)（可重復(fù)

11、（在同一個事務(wù)中，再次讀取數(shù)據(jù)時在同一個事務(wù)中，再次讀取數(shù)據(jù)時【就是你的就是你的selectselect操作操作】，所讀取，所讀取的數(shù)據(jù)，和第的數(shù)據(jù)，和第1 1次讀取的數(shù)據(jù)，不一樣了。查詢的結(jié)果將是不確定的次讀取的數(shù)據(jù)，不一樣了。查詢的結(jié)果將是不確定的）。）。 不可重復(fù)讀解決方案： 鎖住已經(jīng)查詢出來的記錄！不讓其他事物進行寫操作 1.在事務(wù)1中，Mary 讀取了自己的工資為1000, 操作并沒有完成操作并沒有完成 2.在事務(wù)2中，這時財務(wù)人員修改了Mary的工資為2000,并提交了事務(wù).3.在事務(wù)1中，Mary 再次讀取自己的工資時，工資變?yōu)榱?000 可重復(fù)讀（Repeatable Read

12、) 讀事務(wù)會阻塞寫事務(wù)讀事務(wù)會阻塞寫事務(wù)，但是讀事務(wù)不會阻塞讀事務(wù)但是讀事務(wù)不會阻塞讀事務(wù)，寫事寫事務(wù)會阻塞寫事務(wù)和讀事務(wù)。務(wù)會阻塞寫事務(wù)和讀事務(wù)。 讀事務(wù)不阻塞讀事務(wù)(針對的是記錄而不是表)，可能會造成幻讀問題 幻讀解決方案： 解決辦法是鎖表，不讓產(chǎn)生幻讀的記錄插入或刪除。 不過，一般不要考慮幻讀問題。目前工資為1000的員工有10人。 1.事務(wù)1,讀取所有工資為1000的員工。 2.這時事務(wù)2向employee表插入了一條員工記錄，工資也為1000 3.事務(wù)1再次讀取所有工資為1000的員工 共讀取到了11條記錄，序列化（serializable) 此種隔離級別是最嚴(yán)格的隔離級別，如果設(shè)置

13、成這個級別，如果設(shè)置成這個級別，那么就不會出現(xiàn)以上所有的問題（臟讀，不可重復(fù)讀，幻那么就不會出現(xiàn)以上所有的問題（臟讀，不可重復(fù)讀，幻影讀）影讀）。 性能極低，一般不用！我們一般采用讀取已提交或者更低的事務(wù)隔離級別，配合各種并發(fā)訪問控制策略來達到并發(fā)事務(wù)控制的目的。如何使用：2樂觀鎖Optimistic Locking Optimistic Locking 顧名思義就是保持一種樂觀的態(tài)度，我們認(rèn)為系統(tǒng)中的事顧名思義就是保持一種樂觀的態(tài)度，我們認(rèn)為系統(tǒng)中的事務(wù)并發(fā)更新不會很頻繁，即使沖突了也沒事，大不了重新務(wù)并發(fā)更新不會很頻繁，即使沖突了也沒事，大不了重新再來一次。再來一次。 它的基本思想就是每次

14、提交一個事務(wù)更新時，我們想看看它的基本思想就是每次提交一個事務(wù)更新時，我們想看看要修改的東西從上次讀取以后有沒有被其它事務(wù)修改過，要修改的東西從上次讀取以后有沒有被其它事務(wù)修改過，如果修改過，那么更新就會失敗。如果修改過，那么更新就會失敗。 常用實現(xiàn)方法：常用實現(xiàn)方法： 在我們的實體中增加一個版本控制字段，每次事務(wù)更新后就在我們的實體中增加一個版本控制字段，每次事務(wù)更新后就將版本將版本(Version)(Version)字段：版本字段的值加字段：版本字段的值加1.1. 在實體類中增加在實體類中增加Version, private int versionVersion, private int

15、version；getset getset 即可。即可。悲觀鎖Pessimistic LockingPessimistic Locking 基本思想就是每次一個事務(wù)讀取某一條記錄后，就會把這條記錄鎖住，這樣其它的事務(wù)要想更新，必須等以前的事務(wù)提交或者回滾解除鎖。 悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）悲觀鎖： LockMode.NONE：無鎖機制 LockMode.WRITE：Hibernate在Insert和Update記錄的時候會自動獲取 LockMode.READ：Hibernate在讀取記錄的時候會自動獲取 LockMode.UPGRADE：利用數(shù)據(jù)庫的for