原文出自 http://blog.csdn.net/woshichenxu/archive/2006/01/22/586361.aspx

1.     關于hibernate緩 存的問題：

1.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次 查詢的問題

執行條件查詢時，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緩 存的建議

1.4.   目前情況

 一般系統中有三種情況會繞開hibernate執行數據庫操作：

   此種情況使用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 的查詢得到正確的結果,可以使用手動清楚二級緩存中此對象的數據的方法!!

(此種情況出現的可能性較小)

1.5.   建議

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查詢中間表對象的方法，也可以通過調用清除緩存的方法來解決。

4、具體的配置方法 

根據我了解的很多hibernate的使用者在調用其相應方法時都迷信的相信“hibernate會自行為我們處理性能的問題”，或 者“hibernate會自動為我們的所有操作調用緩存”,實際的情況是hibernate雖然為我們提供了很好的緩存機制和擴展緩存框架的支持，但是必 須經過正確的調用其才有可能發揮作用！！所以造成很多使用hibernate的系統的性能問題，實際上并不是hibernate不行或者不好，而是因為使 用者沒有正確的了解其使用方法造成的。相反，如果配置得當hibernate的性能表現會讓你有相當“驚喜的”發現。下面我講解具體的配置方法.

 ibernate提供了二級緩存的接口：
net.sf.hibernate.cache.Provider,
同 時提供了一個默認的 實現net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的實現 比如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使用者在 配置到 這一步 就以為 完事了，
注意：其實光這樣配，根本 就沒有使用hibernate的二級緩存。同時因為他們在使用hibernate時大多時候是馬上關閉session，所以，一級緩存也沒有起到任何作 用。結果就是沒有使用任何緩存，所有的hibernate操作都是直接操作的數據庫！！性能可以想見。

正確的辦法是除了以上的配置外還應該配置每一個vo對象的具體緩存策略，在影射文件中配置。例如：

<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>

關鍵就是這個<cache usage="read-write"/>，其有幾個選擇
read- only,read-write,transactional,等
然后在執行查詢時 注意了 ，如果是條件查詢，或者返回所有結果的查詢，此時session.find()方法 不會獲取緩存中的數據。只有調用query.iterate()方法時才會調緩存的數據。

同時 get 和 load方法 是都會查詢緩存中的數據 .

對于不同的緩存框架具體的配置方法會有不同，但是大體是以上的配置

（另外，對于支持事務型，以及支持集群的環境的配置我會爭取在后續的文章中中 發表出來）

3.     總結

總之是根據不同的業務情況和項目情況 對hibernate進行有效的配置和正確的使用，揚長避短。不存在適合于任何情況的一個“萬能”的方案。

以上結論及建議均建立在自己在對 Hibernate 2.1.2中的測試結果以及以前的項目經驗的基礎上。如有謬處，請打家提 出指正:)!

最后，祝大家 新年快樂！！在新的一年里 取得人生的進步！！！

創建項目：

打開NetBeans 6.5.1，選擇文件—》新建項目，選擇Java Web，然后在項目列表中選擇 Web 應用程序，下一步

選擇使用專用文件夾存儲庫，指定庫文件夾的位置，通常是默認的.\lib，即項目文件夾下的lib文件夾，下一步

選擇Web應用服務器。這里選擇Tomcat 6.0.18 ，Java EE版本選擇 Java EE 5，下一步

在框架對話框中什么都不選擇，直接點擊完成。

配置項目：

1. 配置OperaMask

在WEB-INF文件夾下新建一個faces-config.xml文件，內容如下：

<?xml version="1.0" encoding="UTF-8"?>

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd" version="1.2">

<application>

<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>

</application>

</faces-config>

在新創建的項目中，右鍵單擊“庫”節點，選擇添加庫

然后選擇導入，選擇Spring 2.5庫，選擇導入庫，添加庫。

再次選擇添加庫，然后選擇創建。庫名稱為OperaMask，庫類型為類庫：

在“定制庫”中選擇“添加JAR/文件夾”，在彈出的對話框中選擇OperaMask的基本jar包，并將導入方式指定為：復制到庫文件夾。

一路選是。

2. 配置Spring以及與OperaMask的整合

然后再創建一個OperaMask_SpringCompatibility庫，將OperaMask中的spring文件夾下的operamasks-spring.jar添加進來

然后在新創建的項目中展開WEB-INF文件夾，打開web.xml：按照OperaMask包中的blank樣例程序的配置進行配置。

之后，在web.xml中配置如下內容：

<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext*.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>

然后，在源包節點下創建Spring配置文件applicationContext.xml，選擇如圖所示的幾個命名空間：

選擇完成，然后在Beans節點之間添加如下內容：

<!-- 開啟基于注解的配置 --> <context:annotation-config/> <!-- 使 AOM 中的 LiteBean 同樣能夠被 Spring 所感應到 --> <bean class="org.operamasks.faces.spring.ManagedBeanConfigurer"/>

3. 配置JPA持久化支持

在服務選項卡中，選擇MySQL數據庫驅動，然后右鍵單擊，選擇連接設置，配置你要使用的數據庫：

數據庫配置完畢，然后回到項目選項卡，右鍵單擊剛創建的項目，選擇新建-->其它-->持久性-->持久性單元

在新建持久性單元對話框中選擇持久性庫為Hibernate，即選擇Hibernate為JPA持久單元的實現，數據庫連接選擇我們剛配置好的MySQL連接。

單擊完成。此時，Hibernate的JPA庫已經被添加到項目的lib目錄下了。包含了基本的Hibernate jar包和Hibernate JPA支持jar包。

注：使用JPA的一個好處就是我們不需要在一個統一的配置文件里羅列所有的實體類，而是可以讓實體管理器自動掃描所有被@Entity注解了的實體類。要實現這種功能，如果項目的JPA實現遷移到TopLink Essential，需要加入下面的配置：

找到項目中的“配置文件”節點，打開persistence.xml文件，調整到XML視圖中，在<provider> </provider>節點后添加：

<exclude-unlisted-classes>false</exclude-unlisted-classes> 一行。如果希望使用Hibernate實現，請一定不要加入這一行，否則，您必須將您創建的所有實體類逐一添加到persistence.xml中。

如果要使用Spring提供的JpaTemplate（即實現JpaDaoSupport方式），則回到spring的applicationContext.xml文件，在<beans>節點里面添加：

<!-- 利用Spring的實體管理器工廠來創建JPA實體管理器，傳入的參數為persistence.xml中指定的持久化單元名稱 --> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean"> <property name="persistenceUnitName" value="DMCSv1PU"/> </bean> <!-- 聲明一個Spring提供的JPA事務管理器，傳入的參數正是Spring中的實體管理器工廠 --> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory"/> </bean> <!-- 開啟Spring提供的基于注解的聲明式事務管理 --> <tx:annotation-driven transaction-manager="txManager"/>

至此，持久化支持配置完畢。

創建實體類和相應的JPA控制類

右鍵單擊項目，選擇新建-->其它-->持久性-->通過數據庫生成實體類，選擇數據庫表：

點擊下一步，輸入合適的包名

下一步，映射選項如下圖所示：

選擇新建-->其它-->持久性-->基于實體類的JPA控制器類，下一步：

添加要生成控制器類的實體類，下一步：

選擇合適的包，然后完成。

后面的配置無非就是將JPA的控制器類寫入Spring的配置文件，然后在AOM的LiteBean中注入這些控制器類，實現數據庫操作以及相應的業務邏輯。

注：解決Spring與Hibernate JPA的沖突：

如上圖所示：選擇工具--> 庫 --> 庫位置-->選擇當前編輯的項目，選中Spring Framework 2.5，然后去掉cglib2.2那個jar包。這個包與Hibernate JPA中的cglib 2.1.3.jar有沖突

EM（Web界面的控制臺）：服務器>用戶，查看口令失效的用戶對應的概要文件，這里假設為DEFAULT，下同。

5. 查看對應的概要文件的口令有效期設置

EM（Web界面的控制臺）：服務 器>概要文件>選擇剛剛查到的概要文件DEFAULT>查看，查看口令下面的有效期值。

6.將口令有效期默認值180天 修改成“無限制”（此項要慎重！除非你真得不想要這個密碼失效的機制！）

EM：服務器>概要文件>選擇剛剛查到的概要文件DEFAULT>編輯>口令，在有效期輸入 或選擇你需要的值，保存。

該參數修改實時生效。

出于數據庫安全性考慮，不建議將PASSWORD_LIFE_TIME值設置 成UNLIMITED，即建議客戶能夠定期修改數據庫用戶口令。

在修改PASSWORD_LIFE_TIME值之前已經失效的用戶，還是需 要重新修改一次密碼才能使用。

參數說明：

-Xmx1280m：設置JVM最大可用內存為1280m。最大可設為3550m。具體應用可適當調整。

-Xms1280m：設置JVM初始內存為1280m。此值可以設置與-Xmx相同，以避免每次垃圾回收完成后JVM重新分配內存。

-Xmn480m：設置年輕代大小為480m。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代后，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。

-Xss256k：設置每個線程的堆棧大小。JDK5.0以后每個線程堆棧大小為1M，以前每個線程堆棧大小為256K。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。

-XX:PermSize=64m：指定 jvm 中 Perm Generation 的最小值。 這個參數需要看你的實際情況。可以通過jmap 命令看看到底需要多少。

-XX:MaxPermSize=128m：指定 Perm Generation 的最大值

-XX:+UseConcMarkSweepGC：設置并發收集器

-XX:ParallelGCThreads=8：配置并行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。

-XX:CMSFullGCsBeforeCompaction=0：由于并發收集器不對內存空間進行壓縮、整理，所以運行一段時間以后會產生“碎片”，使得運行效率降低。此值設置運行多少次GC以后對內存空間進行壓縮、整理。

-XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮。可能會影響性能，但是可以消除碎片。

-XX:SurvivorRatio=8：每個survivor space 和 eden之間的比例。

-XX:MaxTenuringThreshold=7：設置垃圾最大年齡。如果設置為0的話，則年輕代對象不經過Survivor區，直接進入年老代。對于年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概率。

-XX:GCTimeRatio=19：設置垃圾回收時間占程序運行時間的百分比，公式為1/(1+n)。

-Xnoclassgc：禁用類垃圾回收，性能會有一定提高。

-XX:+DisableExplicitGC：當此參數打開時，在程序中調用System.gc()將會不起作用。默認是off。

-XX:+UseParNewGC：設置年輕代為并行收集。可與CMS收集同時使用。

-XX:-CMSParallelRemarkEnabled：在使用 UseParNewGC 的情況下 , 盡量減少 mark 的時間。

-XX:CMSInitiatingOccupancyFraction=70：指示在 old generation 在使用了 70% 的比例后 , 啟動 concurrent collector。

-XX:SoftRefLRUPolicyMSPerMB=0：每兆堆空閑空間中SoftReference的存活時間。