为什么要缓存：一句话，减少服务器处理次数，加快访问速度
Ibatis的缓存代码
使用ibatis缓存的方法：
在对应每个表的xml中加入一个cacheModel模块，例如：
代码
<cacheModel id="user-cache" type="LRU" readOnly="false"
serialize="true">
<flushInterval hours="24" />
<flushOnExecute statement="getUser" />
<property value="600" name="size" />
</cacheModel>
id ：cacheModel的id.。
type ：cache的类型.。
ibatis目前提供了LRU,MEMORY,FIFO,OSCACHE这四种.
FIFO：com.ibatis.sqlmap.engine.cache.fifo.FifoCacheController
LRU：com.ibatis.sqlmap.engine.cache.fifo.LruCacheController
MEMORY：com.ibatis.sqlmap.engine.cache.fifo.MemoryCacheController
OSCACHE：com.ibatis.sqlmap.engine.cache.fifo.OSCacheController
当然,你也可以自己来实现Cache, 你需要做的是让你的Cache类 implements com.ibatis.sqlmap.engine.cache.CacheController.
readOnly：是否只读. 默认为true, 只读。
Serialize：是否从Cache中读取同一个对象,还是对象的副本。只有在readOnly=false才有效.
因为Cache是只读的,那么为不同session返回的对象肯定是一个.
只有在Cache是可读写的时候,才需要为每个session返回对象的副本.
flushInterval：Cache刷新间隔. 可以配置hours,minutes,seconds,milliseconds.
注: 不是说,间隔时间到了,在Cache的statement会自己刷新,而是说,在间隔时间过了后,下次的查询
将不会从Cache中直接去值,而会用SQL去查.也就是: 如果,间隔时间过了,还没有Cache对应的statement执行
的话,那么Cache中就会一直是旧的,不用担心Cache数据是旧的,因为下次的查询将会直接从SQL查询,而非Cache,查询的结果也会去更新Cache的值.
flushOnExecute ：当这些statement被执行了,那么下次的查询将会通过SQL去查,同时用查询结果更新Cache.
注: 和flushInterval的刷新一样,不是主动刷新,而是由下次查询来触发被动刷新。
在一个cacheModel中可以指定多个flushOnExecute。
property：这是针对cacheModel的额外的一些属性配置.不同type的cacheModel将会有自己专有的一些property配置.
FIFO: <property name="size" value="100" />
LRU: <property name="cache-size" value="100" />
MEMORY: <property name="reference-type" value="WEAK" />
在statment的使用上，直接加一个cacheModel属性指向id即可。
<select id="getAllUser" resultClass="user" cacheModel="user-cache">
select * from user;
</select>
总结：
1、 感觉ibatis的缓存到了一定的时候就会有瓶颈，在实际应用中如果把数据层的cache做到应用层效果应该会更好。
2、 Ibatis设置cache，当session设为 true 的时候，缓存中存放的对象(你想查询的POJO)必须是可序列化的，即实现Serializable接口，而且只能是jdk自带的序列化。如果你有一个复杂对象属性，它也必须满足这个规则，你的整个对象树必须是可序列化的。