Ibatis Cache配置

转自：http://blog.csdn.net/zhijie435/article/details/1790854

Cache

        在特定硬件基础上（同时假设系统不存在设计上的缺漏和糟糕低效的SQL 语句）Cache往往是提升系统性能的最关键因素）。

        相对Hibernate 等封装较为严密的ORM 实现而言（因为对数据对象的操作实现了较为严密的封装，可以保证其作用范围内的缓存同步，而ibatis 提供的是半封闭的封装实现，因此对缓存的操作难以做到完全的自动化同步）。

        ibatis 的缓存机制使用必须特别谨慎。特别是flushOnExecute 的设定，需要考虑到所有可能引起实际数据与缓存数据不符的操作。如本模块中其他Statement对数据的更新，其他模块对数据的更新，甚至第三方系统对数据的更新。否则，脏数据的出现将为系统的正常运行造成极大隐患。

        如果不能完全确定数据更新操作的波及范围，建议避免Cache的盲目使用。

结合cacheModel来看：

<cacheModel

id="product-cache"

type ="LRU"

readOnly="true"

serialize="false">

</cacheModel>

可以看到，Cache有如下几个比较重要的属性：

Ø readOnly

Ø serialize

Ø type

readOnly

readOnly值的是缓存中的数据对象是否只读。这里的只读并不是意味着数据对象一旦放入缓存中就无法再对数据进行修改。而是当数据对象发生变化的时候，如数据对象的某个属性发生了变化，则此数据对象就将被从缓存中废除，下次需要重新从数据库读取数据，构造新的数据对象。

而readOnly="false"则意味着缓存中的数据对象可更新，如user 对象的name属性发生改变。

只读Cache能提供更高的读取性能，但一旦数据发生改变，则效率降低。系统设计时需根据系统的实际情况（数据发生更新的概率有多大）来决定Cache的读写策略。

serialize

如果需要全局的数据缓存，CacheModel的serialize属性必须被设为true。否则数据缓存只对当前Session（可简单理解为当前线程）有效，局部缓存对系统的整体性能提升有限。

在serialize="true"的情况下，如果有多个Session同时从Cache 中读取某个数据对象，Cache 将为每个Session返回一个对象的复本，也就是说，每个Session 将得到包含相同信息的不同对象实例。因而Session 可以对其从Cache 获得的数据进行存取而无需担心多线程并发情况下的同步冲突。

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来保存当前需要缓存的数据对象的引用。

这里需要注意的是Java2中的三种对象引用关系：

a SoftReference

b WeakReference

c PhantomReference

传统的Java 对象引用，如：

public void doSomeThing(){

User user = new User()

……

}

当doSomeThing方法结束时，user 对象的引用丢失，其所占的内存空间将由JVM在下次垃圾回收时收回。如果我们将user 对象的引用保存在一个全局的HashMap中，如：

Map map = new HashMap();

public void doSomeThing(){

User user = new User();

map.put("user",user);

}

此时，user 对象由于在map 中保存了引用，只要这个引用存在，那么JVM 永远也不会收回user 对象所占用的内存。

这样的内存管理机制相信诸位都已经耳熟能详，在绝大多数情况下，这几乎是一种完美的解决方案。但在某些情况下，却有些不便。如对于这里的Cache 而言，当user 对象使用之后，我们希望保留其引用以供下次需要的时候可以重复使用，但又不希望这个引用长期保存，如果每个对象的引用都长期保存下去的话，那随着时间推移，有限的内存空间将立即被这些数据所消耗殆尽。最好的方式，莫过于有一种引用方式，可以在对象没有被垃圾回收器回收之前，依然能够访问此对象，当垃圾回收器启动时，如果此对象没有被其他对象所使用，则按照常规对其进行回收。

SoftReference、WeakReference、PhantomReference为上面的思路提供了有力支持。

这三种类型的引用都属于“非持续性引用”，也就是说，这种引用关系并非持续存在，它们所代表的引用的生命周期与JVM 的运行密切相关，而非与传统意义上的引用一样依赖于编码阶段的预先规划。

先看一个SoftReference的例子：

SoftReference ref;

public void doSomeThing(){

User user = new User();

ref = new SoftReference(user);

}

public void doAnotherThing(){

User user = (User)ref.get();//通过SoftReference获得对象引用

System.out.println(user.getName());

}

         假设我们先执行了doSomeThing 方法，产生了一个User 对象，并为其创建了一个SoftReference引用。

之后的某个时刻，我们调用了doAnotherThing方法，并通过SoftReference获取User 对象的引用。

        此时我们是否还能取得user 对象的引用？这要看JVM 的运行情况。对于SoftReference而言，只有当目前内存不足的情况下，JVM 在垃圾回收时才会收回其包含的引用（JVM 并不是只有当内存不足时才启动垃圾回收机制，何时进行垃圾回收取决于各版本JVM 的垃圾回收策略。如某这垃圾回收策略为：当系统目前较为空闲，且无效对象达到一定比率时启动垃圾回收机制，此时的空余内存倒可能还比较充裕）。这里可能出现两种情况，即：

Ø JVM 目前还未出现过因内存不足所引起的垃圾回收，user 对象的引用可以通过SoftReference从JVM Heap中收回。

Ø JVM 已经因为内存不足启动了垃圾回收机制，SoftReference所包含的user 对象的引用被JVM 所废弃。此时ref.get方法将返回一个空引用（null），对于上面的代码而言，也就意味着这里可能抛出一个NullPointerException。

WeakReference比SoftReference在引用的维持性上来看更加微弱。无需等到内存不足的情况，只要JVM 启动了垃圾回收机制，那么WeakReference所对应的对象就将被JVM 回收。

        也就是说，相对SoftReference而言，WeakReference 被JVM 回收的概率更大。PhantomReference 比WeakReference 的引用维持性更弱。与WeakReference 和SoftReference不同，PhantomReference所引用的对象几乎无法被回收重用。它指向的对象实际上已经被JVM 销毁（finalize方法已经被执行），只是暂时还没被垃圾回收器收回而已。

        PhantomReference主要用于辅助对象的销毁过程，在实际应用层研发中，几乎不会涉及。

MEMORY类型的Cache正是借助SoftReference、WeakReference以及通常意义上的Java Reference实现了对象的缓存管理。

        下面是一个典型的MEMORY类型Cache配置：

<cacheModel id="user_cache" type="MEMORY">

<flushInterval hours="24"/>

<flushOnExecute statement="updateUser"/>

<property name="reference-type" value="WEAK" />

</cacheModel>

其中flushInterval 指定了多长时间清除缓存，上例中指定每24 小时强行清空缓存区的所有内容。

reference-type属性可以有以下几种配置：

1. STRONG

即基于传统的Java对象引用机制，除非对Cache显式清空（如到了flushInterval设定的时间；执行了flushOnExecute所指定的方法；或代码中对Cache执行了清除操作等），否则引用将被持续保留。

此类型的设定适用于缓存常用的数据对象，或者当前系统内存非常充裕的情况。

2. SOFT

基于SoftReference 的缓存实现，只有JVM 内存不足的时候，才会对缓冲池中的数据对象进行回收。

此类型的设定适用于系统内存较为充裕，且系统并发量比较稳定的情况。

3. WEAK

基于WeakReference 的缓存实现，当JVM 垃圾回收时，缓存中的数据对象将被JVM收回。

一般情况下，可以采用WEAK的MEMORY型Cache配置。

 

LRU型Cache

当Cache达到预先设定的最大容量时，ibatis会按照“最少使用”原则将使用频率最少的对象从缓冲中清除。

<cacheModel id="userCache" type="LRU">

<flushInterval hours="24"/>

<flushOnExecute statement="updateUser"/>

<property name="size" value="1000" />

</cacheModel>

可配置的参数有：

u flushInterval

指定了多长时间清除缓存，上例中指定每24小时强行清空缓存区的所有内容。

u size

Cache的最大容量。

FIFO型Cache

先进先出型缓存，最先放入Cache中的数据将被最先废除。可配置参数与LRU型相同：

<cacheModel id="userCache" type="FIFO">

<flushInterval hours="24"/>

<flushOnExecute statement="updateUser"/>

<property name="size" value="1000" />

</cacheModel>

OSCache

与上面几种类型的Cache不同，OSCache来自第三方组织Opensymphony。可以通过以下网址获得OSCache的最新版本（http://www.opensymphony.com/oscache/）。在生产部署时，建议采用OSCache，OSCache 是得到了广泛使用的开源Cache 实现（Hibernate 中也提供了对OSCache 的支持），它基于更加可靠高效的设计，更重要的是，

最新版本的OSCache 已经支持Cache 集群。如果系统需要部署在集群中，或者需要部署在多机负载均衡模式的环境中以获得性能上的优势，那么OSCache在这里则是不二之选。

Ibatis中对于OSCache的配置相当简单：

<cacheModel id="userCache" type="OSCACHE">

<flushInterval hours="24"/>

<flushOnExecute statement="updateUser"/>

<property name="size" value="1000" />

</cacheModel>

之所以配置简单，原因在于，OSCache拥有自己的配置文件（oscache.properties）J。

下面是一个典型的OSCache配置文件：

#是否使用内存作为缓存空间

cache.memory=true

#缓存管理事件监听器，通过这个监听器可以获知当前Cache 的运行情况

cache.event.listeners=com.opensymphony.oscache.plugins.clustersupport.JMSBroa

dcastingListener

#如果使用磁盘缓存（cache.memory=false），则需要指定磁盘存储接口实现

#cache.persistence.class=com.opensymphony.oscache.plugins.diskpersistence.Disk

PersistenceListener

# 磁盘缓存所使用的文件存储路径

# cache.path=c://myapp//cache

# 缓存调度算法，可选的有LRU,FIFO和无限缓存（UnlimitedCache）

IBATIS Developer’s Guide Version 1.0

September 2, 2004 So many open source projects. Why not Open your Documents?

# cache.algorithm=com.opensymphony.oscache.base.algorithm.FIFOCache

# cache.algorithm=com.opensymphony.oscache.base.algorithm.UnlimitedCache

cache.algorithm=com.opensymphony.oscache.base.algorithm.LRUCache

#内存缓存的最大容量

cache.capacity=1000

# 是否限制磁盘缓存的容量

# cache.unlimited.disk=false

# 基于JMS的集群缓存同步配置

#cache.cluster.jms.topic.factory=java:comp/env/jms/TopicConnectionFactory

#cache.cluster.jms.topic.name=java:comp/env/jms/OSCacheTopic

#cache.cluster.jms.node.name=node1

# 基于JAVAGROUP的集群缓存同步配置

#cache.cluster.properties=UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_

ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout

=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000

):FD_SOCK:VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(gc_lag=50;retransm

it_timeout=300,600,1200,2400,4800):pbcast.STABLE(desired_avg_gossip=20000):

UNICAST(timeout=5000):FRAG(frag_size=8096;down_thread=false;up_thread=fal

se):pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_loc

al_addr=true)

#cache.cluster.multicast.ip=231.12.21.132

配置好之后，将此文件放在CLASSPATH 中，OSCache 在初始化时会自动找到此文件并根据其中的配置创建缓存实例。