ehcache2.4的源码分析 ---- 缓存失效机制
首先说一下ehcache的好处。
ehcache是本机缓存，而非memcache是远程缓存，ehcache的缓存是在当前jvm里的，这使得内存是可重用的。所以其性能是远过memcache的。
1、免去了远程IO时间。
2、免去了memcache这种取回来以后要申请内存的时间。
3、大大差少了full gc的次数。
ehcache的缓存方式与cuncurrentHashmap相似，一系列segment，每个segment里有一个hashmap这种。
下面介绍正题，它的缓存失效机制。我会在最下面贴出我的配置，请大家看看我是不是配的有问题。
一、网上说，这个玩意他有一个后台的守护线程，在不定时的清理缓存。还说设置diskExpiryThreadIntervalSeconds能影响这个线程运行间隔时间。
我在2.4里没找着这个代码。jvm里也没有这个线程。
里面虽有一个用java.util.timer这个定时器开启的后台线程，但是它只启动了一个自动更新的程序。
所以我认为网上又在以讹传讹了。
二、LRU、LFU 和 FIFO
我本是想看看他的lru算法是怎么实现的，但是看了以后很失望，又想了一会感觉其实实现的也很好，缓存不用清的那么精确。
他是这样实现的：
他有一个基数是30.
比如你现在设了缓存最大数是10，你put了10个缓存进去。当你put第11个的时候，他对比10和30，取最小值10，把10个缓存都取出来，或lru或fifo。
比如你现在设了缓存最大数是1000，你put了1000个缓存进去。当你put第1001个的时候，他对比1000和30，取最小值30，然后随机在缓存里找出30个缓存出来，或lru或fifo。
看到了吧，他的缓存清理机制不怎么精确。
这个代码的位置：
net.sf.ehcache.store.compound.Segment的put方法的这句Object encoded = create(key, element);里执行的上面的动作。
然后进入了net.sf.ehcache.store.compound.factories.CapacityLimitedInMemoryFactory这个类执行的public Element create(Object key, Element element)进行清理。
这是我这两天看这个代码得到的结果。
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ehcache.xsd">
<diskStore path="java.io.tmpdir"/>
<cacheManagerEventListenerFactory properties=""/>
<!--<diskStore?path="java.io.tmpdir"/>
-->
<cacheManagerPeerListenerFactory
properties="peerDiscovery=manual,rmiUrls=//192.168.27.125:10001/user" />
<defaultCache
maxElementsInMemory="10"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="true"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"
memoryStoreEvictionPolicy="LRU"
/>
<!-- WEB cache-->
<cache name="user"
maxElementsInMemory="1000"
maxElementsOnDisk="1000"
eternal="false"
overflowToDisk="false"
diskPersistent="false"
memoryStoreEvictionPolicy="LRU"
timeToIdleSeconds="600"
timeToLiveSeconds="0"
diskSpoolBufferSizeMB="50"
diskExpiryThreadIntervalSeconds="10"
>
<cacheEventListenerFactory />
</cache>
</ehcache>
