二級緩存是SessionFactory級別的全局緩存，它底下可以使用不同的緩存類庫，比如ehcache、oscache等，需要設置hibernate.cache.provider_class，我們這裏用
ehcache，即配置
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProviderhibernate.cache.use_query_cache=true1 二級緩存的工作內容
Hibernate的二級緩存同一級緩存一樣，也是針對對象ID來進行緩存。所以說，二級緩存的作用範圍是針對根據ID獲得對象的查詢。
二級緩存的工作可以概括爲以下幾個部分：
● 在執行各種條件查詢時，如果所獲得的結果集爲實體對象的集合，那麼就會把所有的數據對象根據ID放入到二級緩存中。
● 當Hibernate根據ID訪問數據對象的時候，首先會從Session一級緩存中查找，如果查不到並且配置了二級緩存，那麼會從二級緩存中查找，如果還查不到，就會查詢數據庫，把結果按照ID放入到緩存中。
● 刪除、更新、增加數據的時候，同時更新緩存。
2 二級緩存的適用範圍
Hibernate的二級緩存作爲一個可插入的組件在使用的時候也是可以進行配置的，但並不是所有的對象都適合放在二級緩存中。
在通常情況下會將具有以下特徵的數據放入到二級緩存中：
● 很少被修改的數據。
● 不是很重要的數據，允許出現偶爾併發的數據。
● 不會被併發訪問的數據。
● 參考數據。
而對於具有以下特徵的數據則不適合放在二級緩存中：
● 經常被修改的數據。
● 財務數據，絕對不允許出現併發。
● 與其他應用共享的數據。
在這裏特別要注意的是對放入緩存中的數據不能有第三方的應用對數據進行更改（其中也包括在自己程序中使用其他方式進行數據的修改，例如，JDBC），因爲那樣Hibernate將不會知道數據已經被修改，也就無法保證緩存中的數據與數據庫中數據的一致性。
3 二級緩存組件
在默認情況下，Hibernate會使用EHCache作爲二級緩存組件。但是，可以通過設置 hibernate.cache.provider_class屬性，指定其他的緩存策略，該緩存策略必須實現 org.hibernate.cache.CacheProvider接口。
通過實現org.hibernate.cache.CacheProvider接口可以提供對不同二級緩存組件的支持。
Hibernate內置支持的二級緩存組件如表14.1所示。
表1 Hibernate所支持的二級緩存組件
|
組件 |
Provider類 |
類型 |
集羣 |
查詢緩存 |
|
Hashtable |
org.hibernate.cache.HashtableCacheProvider |
內存 |
不支持 |
支持 |
|
EHCache |
org.hibernate.cache.EhCacheProvider |
內存，硬盤 |
最新支持 |
支持 |
|
OSCache |
org.hibernate.cache.OSCacheProvider |
內存，硬盤 |
不支持 |
支持 |
|
SwarmCache |
org.hibernate.cache.SwarmCacheProvider |
集羣 |
支持 |
不支持 |
|
JBoss TreeCache |
org.hibernate.cache.TreeCacheProvider |
集羣 |
支持 |
支持 |
Hibernate已經不再提供對JCS（Java Caching System）組件的支持了。
4 Class的緩存對於一條記錄，也就是一個PO來說，是根據ID來找的，緩存的key就是ID，value是POJO。無論list，load還是iterate，只要讀出一個對象，都會填充緩存。
但是list不會使用緩存，而iterate會先從數據庫select id出來，然後一個id一個id的load，如果在緩存裏面有，就從緩存取，沒有的話就去數據庫load。假設是讀寫緩存，需要設置：
<cache usage="read-write"><span style="font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);">如果你使用的二級緩存實現是ehcache的話，需要配置ehcache.xml</span><pre name="code" class="html"><cache name="com.xxx.pojo.Foo"
maxElementsInMemory="500"
eternal="false"
timeToLiveSeconds="7200"
timeToIdleSeconds="3600"
overflowToDisk="true">這樣大家可能會想，同樣的查詢條件，第一次先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"/> <cache name="org.hibernate.cache.StandardQueryCache"
maxElementsInMemory="5000"
eternal="false"
timeToLiveSeconds="3600"
overflowToDisk="false"/>
<pre name="code" class="html"><cache name="org.hibernate.cache.UpdateTimestampsCache"
maxElementsInMemory="5000"
eternal="true"
overflowToDisk="true"/>query.setCacheable(true);//激活查詢緩存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可選<cache name="myCacheRegion"
maxElementsInMemory="10"
eternal="false"
timeToIdleSeconds="3600"
timeToLiveSeconds="7200"
overflowToDisk="true" />對於查詢緩存來說，緩存的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"<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />這樣有一個問題，如果你的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.----------------------------------------------------
總結：
不要想當然的以爲緩存一定能提高性能，僅僅在你能夠駕馭它並且條件合適的情況下才是這樣的。hibernate的二級緩存限制還是比較多的，不方便用jdbc可能會大大的降低更新性能。在不瞭解原理的情況下亂用，可能會有1+N的問題。不當的使用還可能導致讀出髒數據。
如果受不了hibernate的諸多限制，那麼還是自己在應用程序的層面上做緩存吧。
在越高的層面上做緩存，效果就會越好。就好像儘管磁盤有緩存，數據庫還是要實現自己的緩存，儘管數據庫有緩存，咱們的應用程序還是要做緩存。因爲底層的緩存它並不知道高層要用這些數據幹什麼，只能做的比較通用，而高層可以有針對性的實現緩存，所以在更高的級別上做緩存，效果也要好些吧。