（一）hibernate数据缓存策略
  缓存是数据库数据在内存中的临时容器，它包含了库表数据在内存中的拷贝，位于数据库与数据访问层之间。对于查询操作相当频繁的系统（论坛，新闻发布等），良好的缓存机制显得尤为重要。
  ORM在进行数据读取时，首先在缓存中查询，避免了数据库调用的性能开销。
ORM的数据缓存应包含下面几个层次：
1）事务级缓存   2）应用级缓存   3）分布式缓存
具体针对Hibernate而言，采用两级缓存策略，其过程描述：
(1)条件查询的时候，总是发出一条select * from table_name where …. 这样的SQL语句查询数据库，一次获得所有的数据对象。
(2) 把获得的所有数据对象根据ID放入到第二级缓存中。
(3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
(4) 删除、更新、增加数据的时候，同时更新缓存。
1. 一级缓存(session level)－数据库事务级缓存
  1）根据主键id加载数据时。 Session.load()， Session.iterate()方法
    2）延迟加载时
    Session内部维护一个数据对象集合，包括了本Session内选取的、操作的数据对象。这称为Session内部缓存，是Hibernate的第一级最快缓存，属于Hibernate的既定行为，不需要进行配置(也没有办法配置 :-)。
    内部缓存正常情况下由hibernate自动维护，但也可人工干预：
            1) Session.evict (): 将某个特定对象从内部缓存中清除
            2)Session.clear(): 清空内部缓存
2.二级缓存(SessionFactory level)－应用级缓存
    二级缓存由SessionFactory的所有session实例共享。
3. 第三方缓存实现
    EHCache, OSCahe
hibernate批量查询引起的内存溢出问题
    批量查询基本不适合使用现有的持久层技术来做，如CMP或hibernate，IBatis倒是可以.
    因为每次调用Session.save()方法时，当前session都会将对象纳入到自身的内部缓存中。内部缓存不同于二级缓存，我们可以在二级缓存的配置中指定其最大容量。
解决方案：
1）在批处理情况下，关闭Hibernate缓存，如果关闭Hibernate缓存，那么和直接使用JDBC就没有区别。
2） 每隔一段时间清空Session内部缓存
  Session实现了异步write-behind，它允许Hibernate显式地写操作的批处理。 这里，我给出Hibernate如何实现批量插入的方法： 首先，我们设置一个合理的JDBC批处理大小，hibernate.jdbc.batch_size 20。 然后在一定间隔对Session进行flush()和clear()。
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i % 20 == 0 ) {
//flush 插入数据和释放内存:
session.flush(); session.clear(); }
}
tx.commit();
session.close();
  为了优化性能，可执行批量操作。在传统的JDBC编程中，批量操作方式如下，将数个SQL操作批量提交：
PrepareStatement ps=conn.prepareStatement("insert into users(name) values(?)");  
for(int i=0;i<100000;i++){
  ps.setString(1, "user"+i);
  ps.addBatch();
}
int[] counts=ps.executeBatch
在Hibernate中，可以设置hibernate.jdbc.batch_size 参数来指定每次提交的sql数量。
hibernate2和hibernate3数据批量删除机制分析
1.hibernate2
    Transaction tx=session.beginTransaction();
    session.delete("from users");
    tx.commit();
  观察日志输出：
select ... from users
Hibernate:delete from users where id=?
Hibernate:delete from users where id=?
Hibernate:delete from users where id=?
...
    hibernate2版本会首先从数据库中查询出所有符合条件的记录，再对此记录循环删除。如果记录量过大，势必引起内存溢出和删除效率问题。ORM为什么要这么做呢？因为ORM为了自动维护内存状态，必须知道用户到底对哪些数据进行了操作。问题的解决方法：
1）内存消耗
    批量删除前首先从数据库中查询出所有符合条件的记录，如果数据量过大，就会导致 OutOfMemoryError.
    可以采用Session .iterate或Query.iterate方法逐条获取记录，再执行delete操作。另外，hibernate2.16后的版本提供了基于游标的数据遍历操作：
Transaction tx=session.beginTransaction();
String hql="from users";
Query query=session.createQrery(hql);
ScrollableResults sr=query.scroll();
while(sr.next()){
TUser user=(TUser)sr.get(0);
session.delete();
}
tx.commit();
2）循环删除的效率问题
  由于hibernate在批量删除操作过程中，需要反复调用delete SQL，存在性能问题。我们仍然可以通过调整hibernate.jdbc.batch_size参数来解决。
2.hibernate3
  hibernate3 HQL中引入了 bulk delete/update操作， 即通过一条独立的sql语句来完成数据的批量操作。
Transaction tx=session.beginTransaction();
String hql="delete TUser";
Query query=session.createQrery(hql);
int count=query.executeUpdate();
tx.commit();
观察日志输出：
Hibernate:delete from TUser

（二）ibatis数据缓存
  相对Hibernate 等封装较为严密的ORM 实现而言（因为对数据对象的操作实现
了较为严密的封装，可以保证其作用范围内的缓存同步，而ibatis 提供的是半封闭
的封装实现，因此对缓存的操作难以做到完全的自动化同步）。
  ibatis 的缓存机制使用必须特别谨慎。特别是flushOnExecute 的设定（见
“ibatis配置”一节中的相关内容），需要考虑到所有可能引起实际数据与缓存数据
不符的操作。如本模块中其他Statement对数据的更新，其他模块对数据的更新，甚
至第三方系统对数据的更新。否则，脏数据的出现将为系统的正常运行造成极大隐患。
如果不能完全确定数据更新操作的波及范围，建议避免Cache的盲目使用。
1.iBatis cache设置
sqlmap-config.xml在<sqlMapConfig>里面加入
<settings
  cacheModelsEnabled="true"
  enhancementEnabled="true"
  lazyLoadingEnabled="true" />
maps.xml在<sqlMap>里面加入
<cacheModel   id="userCache"   type="LRU"   readonly="true"   serialize="false">
    <flushInterval hours="24"/>
    <flushOnExecute statement="insertTest"/>
    <property name="size" value="1000" />
</cacheModel>
可以看到，Cache有如下几个比较重要的属性：readOnly，serialize，type

readOnly
  readOnly值的是缓存中的数据对象是否只读。这里的只读并不是意味着数据对象一
旦放入缓存中就无法再对数据进行修改。而是当数据对象发生变化的时候，如数据对
象的某个属性发生了变化，则此数据对象就将被从缓存中废除，下次需要重新从数据
库读取数据，构造新的数据对象。
serialize
  如果需要全局的数据缓存，CacheModel的serialize属性必须被设为true。否则数据缓存只对当前Session（可简单理解为当前线程）有效，局部缓存对系统的整体性能提升有限。
Cache Type:
  与hibernate类似，ibatis通过缓冲接口的插件式实现，提供了多种Cache的实现机制可供选择：
1． MEMORY
2． LRU
3． FIFO
4． OSCACHE
MEMORY类型Cache与WeakReference
    MEMORY 类型的Cache 实现，实际上是通过Java 对象引用进行。ibatis 中，其实现类
为com.ibatis.db.sqlmap.cache.memory.MemoryCacheController，MemoryCacheController 内部，
使用一个HashMap来保存当前需要缓存的数据对象的引用。
LRU型Cache
    当Cache达到预先设定的最大容量时，ibatis会按照“最少使用”原则将使用频率最少
的对象从缓冲中清除。可配置的参数有：
flushInterval：指定了多长时间清除缓存，上例中指定每24小时强行清空缓存区的所有内容。
size
FIFO型Cache
先进先出型缓存，最先放入Cache中的数据将被最先废除。
OSCache
（三）开源数据缓存策略OSCache
可以解决的问题：
1）信息系统中需要处理的基础数据的内容短时间内是不会发生变化的，但是在一个相对长一些的时间里，它却可能是动态增加或者减少的。
2）统计报表是一个周期性的工作，可能是半个月、一个月或者更长的时间才会需要更新一次，然而统计报表通常是图形显示或者是生成pdf、word、excel等格式的文件，这些图形内容、文件的生成通常需要消耗很多的系统资源，给系统运行造成很大的负担。
    OSCache是OpenSymphony组织提供的一个J2EE架构中Web应用层的缓存技术实现组件。OSCache支持对部分页面内容或者对页面级的响应内容进行缓存，编程者可以根据不同的需求、不同的环境选择不同的缓存级别。可以使用内存、硬盘空间、同时使用内存和硬盘或者提供自己的其他资源（需要自己提供适配器）作为缓存区。
使用步骤：
1. 下载、解压缩OSCache
请到OSCache的主页http://www.opensymphony.com/oscache/download.html下载Oscache的最新版本，作者下载的是OSCache的最新稳定版本2.0。
将下载后的。Zip文件解压缩到c:\oscache（后面的章节中将使用%OSCache_Home%来表示这个目录）目录下
2. 新建立一个web应用
3. 将主要组件%OSCache_Home%\oscache.jar放入WEB-INF\lib目录
4. commons-logging.jar、commons-collections.jar的处理
•      OSCache组件用Jakarta Commons Logging来处理日志信息，所以需要commons-logging.jar的支持，请将%OSCache_Home%\lib\core\commons-logging.jar放入classpath（通常意味着将这个文件放入WEB-INF\lib目录）
•      如果使用JDK1.3,请将%OSCache_Home%\lib\core\commons-collections.jar放入classpath，如果使用JDK1.4或者以上版本，则不需要了
5. 将oscache.properties、oscache.tld放入WEB-INF\class目录
•      %OSCache_Home%\oscache.properties包含了对OSCache运行特征值的设置信息
•      %OSCache_Home%\oscache.tld包含了OSCache提供的标签库的定义内容
6. 修改web.xml文件
在web.xml文件中增加下面的内容，增加对OSCache提供的taglib的支持：
<taglib><taglib-uri>oscache</taglib-uri><taglib-location>/WEB-INF/classes/oscache.tld</taglib-location></taglib>
7.最简单的cache标签用法
使用默认的关键字来标识cache内容，超时时间是默认的3600秒
<cache:cache><%//自己的JSP代码内容%></cache:cache>
8. 缓存单个文件
      在OSCache组件中提供了一个CacheFilter用于实现页面级的缓存，主要用于对web应用中的某些动态页面进行缓存，尤其是那些需要生成pdf格式文件/报表、图片文件等的页面，不仅减少了数据库的交互、减少数据库服务器的压力，而且对于减少web服务器的性能消耗有很显著的效果。
修改web.xml，增加如下内容，确定对/testContent.jsp页面进行缓存。
<filter>     <filter-name>CacheFilter</filter-name><filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class></filter><filter-mapping><filter-name>CacheFilter</filter-name><!-对/testContent.jsp页面内容进行缓存-->     <url-pattern>/testContent.jsp</url-pattern></filter-mapping>

另一篇：
很多人对二级缓存都不太了解，或者是有错误的认识，我一直想写一篇文章介绍一下hibernate的二级缓存的，今天终于忍不住了。
我的经验主要来自hibernate2.1版本，基本原理和3.0、3.1是一样的，请原谅我的顽固不化。
hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了。
二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置hibernate.cache.provider_class，我们这里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查询缓存，加上
hibernate.cache.use_query_cache=true
缓存可以简单的看成一个Map，通过key在缓存里面找value。
Class的缓存
对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：
<cache usage="read-write"/>
如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml
<cache name="com.xxx.pojo.Foo" maxElementsInMemory="500" eternal="false" timeToLiveSeconds="7200" timeToIdleSeconds="3600" overflowToDisk="true" />
其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果eternal="false"，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put的元素超过500个时，如果overflowToDisk="true"，就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。
当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。
这样大家可能会想，同样的查询条件，第一次先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"/>
然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选
第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：
<cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" />
如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache
对于查询缓存来说，缓存的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"/>
假如class是Cat，collection叫children，那么ehcache里面配置
<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题，如果你的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.
不过我不建议这样做，因为这样很难维护。比如你现在用JDBC批量更新了某个表，有3个查询缓存会用到这个表，用evictQueries(String cacheRegion)移除了3个查询缓存，然后用evict(Class persistentClass)移除了class缓存，看上去好像完整了。不过哪天你添加了一个相关查询缓存，可能会忘记更新这里的移除代码。如果你的jdbc代码到处都是，在你添加一个查询缓存的时候，还知道其他什么地方也要做相应的改动吗？
----------------------------------------------------
总结：
不要想当然的以为缓存一定能提高性能，仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的，不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用，可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制，那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存，效果就会越好。就好像尽管磁盘有缓存，数据库还是要实现自己的缓存，尽管数据库有缓存，咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么，只能做的比较通用，而高层可以有针对性的实现缓存，所以在更高的级别上做缓存，效果也要好些吧。
转自：http://blog.ccidnet.com/blog-htm-do-showone-uid-44291-type-blog-itemid-125551.html