cache是老生常谈的事情，但开始这个题目之前，我想先强调一下KISS原则，就是keep it simple and stupid。最近看到很多场景下cache使用的不适当，特别是被过度使用了。一个简单键值存储并不需要复杂的cache方案，好的方案就是用最简单的方法解决问题。简洁是美！

一个标准Cache的主要特征是：

过期时间       

容量规划(重要)

清除策略(重要)

命中率统计 

基于以上特征，使用HashMap作为本地cache似乎很不适当。更重要的是，有不少朋友认为HashMap可能会使内存耗尽。其实不然，自 jdk1.2后，Java就引入了WeakHashMap。看看api文档是怎么说的：对于一个给定的键，其映射的存在并不阻止垃圾回收器对该键的丢弃，这就使该键成为可终止的，被终止，然后被回收。丢弃某个键时，其条目从映射中有效地移除，因此，该类的行为与其他的 Map 实现有所不同。

这个翻译明显有点烂，总结一下，和强引用的HashMap相比，WeakHashMap在本身引用不被回收的前提下允许GC回收它的键值对。当GC 发现内存即将耗尽且没有其他对象可以释放时，会主动回收WeakHashMap所占用的对象。因此使用WeakHashMap作为本地cache是不会造成内存耗尽。如果你仅仅需要一个简单的键值对存储，而并不关心命中率统计，那么放心的使用WeakHashMap作为cache吧。

通过简单的包装，就可以为你的HashMap增加过期时间和容量规划。而且比其他cache更高效。openfire的DefaultCache就是一个很好的例子：http://svn.igniterealtime.org/svn/repos/openfire/trunk/src/java /org/jivesoftware/util/cache/DefaultCache.java

DefaultCache的核心是HashMap，另外增加了一层很薄的包装来实现过期和LRU。DefaultCache包括两个 LinkedList，一个用于存储插入顺序，另一个用于存储插入时间。当添加cache时，都addFirst。当cache size达到临界值时，从最尾部删除。有朋友测试过，比ehcache快5倍。

如果本地cache不能满足你的要求，ehcache是个很好的选择。不仅仅作为分布式的cache，甚至作为状态同步，ehcache都有非常优秀的案例。也可以实现多机copy。分享一个数据，某生产系统中ehcache每天处理17,466,415次replication。

基于ehcache的分布式缓存，你可以简单的实现分布式计算。分析一个场景，某ios后端服务要求用户先注册ios设备，可以按下图处理设备信息。DeviceServer接受device注册后同步copy的本地cache和ehcache。该ehcache按以下方式配置成对。本地 cache再定期（每隔几秒钟）从ehcache中加载peer server注册的数据。

<cacheManagerPeerProviderFactory  class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"  properties="peerDiscovery=manual,rmiUrls=//192.168.0.1:20121/testCache"/>  <cacheManagerPeerListenerFactory  class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"  properties="hostName=192.168.0.2,port=20121,socketTimeoutMillis=60000"/>    <cache name="testCache"  maxElementsInMemory="20000"  eternal="false"  overflowToDisk="false"  memoryStoreEvictionPolicy="LRU">  <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"  properties="replicateAsynchronously=true,  replicatePuts=true,  replicateUpdates=true,  replicateUpdatesViaCopy=true,  asynchronousReplicationIntervalMillis=2000"  />  </cache>