查詢優(yōu)化和緩存問題一級緩存的管理應用程序調(diào)用Session的save()、update()、saveOrUpdate()、get()或load()，以及調(diào)用查詢接口的list()、iterate()時，如果在Session緩存中還不存在相應的對象，Hibernate就會把該對象加入到第一級緩存中?？梢酝ㄟ^close/clear/evict清空緩存作用因為Session的生命期往往很短，存在于Session內(nèi)部的第一級最快緩存的生命期當然也很短，所以第一級緩存的命中率是很低的。其對系統(tǒng)性能的改善也是很有限的。Session內(nèi)部緩存的主要作用是保持Session內(nèi)部數(shù)據(jù)狀態(tài)同步。一級緩存（Session緩存）開啟：<propertyname="hibernate.cache.use_second_level_cache">true</property><propertyname="vider_class">org.hibernate.cache.EhCacheProvider</property>如何使用：類定義前面：@cache，指該類的對象都會放入二級緩存。

@Cache(usage=CacheConcurrencyStrategy.READ_WRITE)//放入二級緩存中也可以被修改。一般用它。什么內(nèi)容時候放入二級緩存：經(jīng)常被訪問、改動不頻繁、數(shù)量有限。二級緩存(SessionFactory緩存)load都會使用二級緩存。注意：load和get的主要區(qū)別回顧：搜索不到符合條件的記錄，get返回一個null，load會拋出一個ObjectNotFountdExceptionget會使用一級緩存，不會使用二級。Load會使用二級緩存Load有懶加載。Get直接獲得數(shù)據(jù)對象iterate也會使用二級緩存。list默認會往二級緩存中存放數(shù)據(jù)，即通過list查出的結果會放入二級緩存。但是list本身查詢時不會使用二級緩存。二級緩存(SessionFactory緩存)緩存插件支持只讀支持非嚴格讀寫支持讀寫支持事務EhCache是是是

OSCache是是是

SwarmCache是是

JBossCache是

是各種二級緩存插件查詢緩存只對query.list()起作用查詢緩存依賴于二級緩存，因此一定要打開二級緩存。查詢緩存實現(xiàn)機制：以查詢語句為key，查到的對象的id為value查詢緩存的配置和使用：開啟二級緩存<propertyname="hibernate.cache.use_query_cache">true</property>//默認是fasle

在程序中必須手動啟用查詢緩存，如：query.setCacheable(true);

查詢緩存緩存滿了后，將內(nèi)存中哪個對象清掉。LRULeastRecentlyUsed最近最少被使用的。每個緩存對象都記錄一個最后使用時間。LFULeastFrequentlyUsed最近使用頻率最少。FIFOFirstInFirstOut緩存算法問題在一對多/多對一中，經(jīng)常出現(xiàn)1+N問題。在1方，查找得到了n個對象，那么又需要將n個對象關聯(lián)的集合取出，于是本來的一條sql查詢變成了n+1條。解決方案：懶加載@OneToMany(mappedBy=“banji”,fetch=FetchType.LAZY)(默認即為此)二級緩存在對象更新，刪除，添加相對于查詢要少得多時，二級緩存的應用將不怕n+1問題，因為即使第一次查詢很慢，之后直接緩存命中也是很快的，剛好又利用了n+1。1+N問題List僅僅會填充二級緩存，卻不能利用二級緩存。iterator可以讀二級緩存，對于一條查詢語句，它會先從數(shù)據(jù)庫中找出所有符合條件的記錄的ID，再通過ID去緩存找，對于緩存中沒有的記錄，再構造語句從數(shù)據(jù)庫中查出。在緩存中沒有命中的話，效率很低。最好的辦法就是：在應用啟動時和數(shù)據(jù)被修改時使用list。平時則使用iterator。（只針對修改不頻繁的數(shù)據(jù)?。㎜ist和iterator區(qū)別一般開始開發(fā)并不使用緩存機制。根據(jù)需求如果不能滿足性能要求，才增加緩存。二級緩存：緩存數(shù)據(jù)內(nèi)容變化頻率不高的內(nèi)容。查詢緩存很多系統(tǒng)經(jīng)常在應用層增加緩存：OSCACHE在J2EE中的應用緩存機制的選用建議：大批量數(shù)據(jù)的處理不要使用hibernate,優(yōu)先考慮JDBC的批量處理。（一般使用JDBC）如果對性能要求極高，可以考慮PL/SQL數(shù)據(jù)批量處理數(shù)據(jù)量巨大，性能要求高，hibernate由于在ORM映射中對系統(tǒng)資源消耗也比較高，所以不適合。Hibernate適合：邏輯復雜，數(shù)據(jù)量不大。sessionFactory的創(chuàng)建非常消耗資源，整個應用一般只要一個。將所有的集合屬性配置設置為懶加載。Hibernate2.x默認是false,hibernate3.x默認是true在定義關聯(lián)關系時，集合首選Set，如果集合中的實體存在重復，則選擇List，數(shù)組性能最差。在一對多的雙向關聯(lián)中，一般將集合的inverse設置為true，讓集合的對方維護關聯(lián)關系。HQL子句本身大小寫無關，但是其中出現(xiàn)的類名和屬性名必須注意大小寫區(qū)分。對大數(shù)據(jù)量查詢時，慎用list()返回查詢結果在性能瓶頸的地方使用JDBC。使用雙向關聯(lián)。在大型應用中，幾乎所有的關聯(lián)必須在查詢中可以雙向?qū)Ш健ibernate最佳實踐事務基本概念ACID即是atomicity（原子性），consistency（一致性），isolation（隔離性）和durability（執(zhí)久性）的首字母的縮寫原子性表示一個事務內(nèi)的所有操作是一個整體，要么全部成功，要么全失?。灰恢滦员硎疽粋€事務內(nèi)有一個操作失敗時，所有的更改過的數(shù)據(jù)都必須回滾到修改前的狀態(tài)；隔離性：事務查看數(shù)據(jù)時數(shù)據(jù)所處的狀態(tài)，要么是另一并發(fā)事務修改它之前的狀態(tài)，要么是另一事務修改它之后的狀態(tài)，事務不會查看中間狀態(tài)的數(shù)據(jù)。持久性事務完成之后，它對于系統(tǒng)的影響是永久性的。事務隔離級別從低到高：讀取未提交（Readmitted)讀取已提交(ReadCommitted)可重復讀（RepeatableRead)序列化（serializable)事務隔離級別讀取未提交（Readmitted)這是最低的事務隔離級別，讀事務不會阻塞讀事務和寫事務，寫事務也不會阻塞讀事務，但是會阻塞寫事務。寫事務不阻塞讀事務，可以讀取未提交的數(shù)據(jù)，容易造成臟讀臟讀現(xiàn)象：臟讀解決方案：如果在第一個事務提交前，任何其他事務不可讀取其修改過的值，則可

以避免該問題。事務隔離級別1.Mary的原工資為1000,財務人員將Mary的工資改為了8000(但未提交事務)

2.Mary讀取自己的工資

,發(fā)現(xiàn)自己的工資變?yōu)榱?000，歡天喜地！3.而財務發(fā)現(xiàn)操作有誤，回滾了事務,Mary的工資又變?yōu)榱?000

像這樣,Mary記取的工資數(shù)8000是一個臟數(shù)據(jù)。讀取已提交(ReadCommitted)寫事務就會阻塞讀事務和寫事務，但是讀事務不會阻塞讀事務和寫事務。讀事務不阻塞寫事務，但是有可能造成不可重復（在同一個事務中，再次讀取數(shù)據(jù)時【就是你的select操作】，所讀取的數(shù)據(jù)，和第1次讀取的數(shù)據(jù)，不一樣了。查詢的結果將是不確定的）。不可重復讀解決方案：鎖住已經(jīng)查詢出來的記錄！不讓其他事物進行寫操作事務隔離級別（一般采用此級別）

1.在事務1中，Mary讀取了自己的工資為1000,操作并沒有完成

2.在事務2中，這時財務人員修改了Mary的工資為2000,并提交了事務.3.在事務1中，Mary再次讀取自己的工資時，工資變?yōu)榱?000可重復讀（RepeatableRead)讀事務會阻塞寫事務，但是讀事務不會阻塞讀事務，寫事務會阻塞寫事務和讀事務。讀事務不阻塞讀事務(針對的是記錄而不是表)，可能會造成幻讀問題幻讀解決方案：解決辦法是鎖表，不讓產(chǎn)生幻讀的記錄插入或刪除。不過，一般不要考慮幻讀問題。事務隔離級別目前工資為1000的員工有10人。

1.事務1,讀取所有工資為1000的員工。

2.這時事務2向employee表插入了一條員工記錄，工資也為10003.事務1再次讀取所有工資為1000的員工

共讀取到了11條記錄，序列化（serializable)此種隔離級別是最嚴格的隔離級別，如果設置成這個級別，那么就不會出現(xiàn)以上所有的問題（臟讀，不可重復讀，幻影讀）。性能極低，一般不用！事務隔離級別我們一般采用讀取已提交或者更低的事務隔離級別，配合各種并發(fā)訪問控制策略來達到并發(fā)事務控制的目的。如何使用：事務隔離級別最佳實踐<!--制定事務隔離級別：1,2,4,8。二進制中：0001,0010,0100,1000。這樣直接采用位運算即可。權限控制中經(jīng)常采用二進制位運算--><propertyname="hibernate.connection.isolation">2</property>樂觀鎖OptimisticLocking顧名思義就是保持一種樂觀的態(tài)度，我們認為系統(tǒng)中的事務并發(fā)更新不會很頻繁，即使沖突了也沒事，大不了重新再來一次。它的基本思想就是每次提交一個事務更新時，我們想看看要修改的東西從上次讀取以后有沒有被其它事務修改過，如果修改過，那么更新就會失敗。常用實現(xiàn)方法：在我們的實體中增加一個版本控制字段，每次事務更新后就將版本(Version)字段：版本字段的值加1.在實體類中增加@Version,privateintversion；getset即可。樂觀鎖和悲觀鎖(了解)悲觀鎖PessimisticLocking基本思想就是每次一個事務讀取某一條記錄后，就會把這條記錄鎖住，這樣其它的事務要想更新，必須等以前的事務提交或者回滾解除鎖。悲觀鎖的實現(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ù)庫的forupdate子句加鎖LockMode.