java实现cache的基本原则

我这里说的cache不是指CPU和RAM之间的缓存，而是java应用中间常用的缓存。最常使用的场合就是访问数据库的时候为了提高效率而使用的 cache。一般的用法就是把数据从数据库读到内存，然后之后的数据访问都从内存来读，从而减少对数据库的读取次数来提高效率。

   在使用cache的时候最容易犯的错误就是cache涉及了业务逻辑。使用cache的原意是只是提高程序效率，而不应该干涉程序结果。按照cahce的定义，cache应该是对数据访问端透明 地工作。所以在使用cache的时候我们可以问一下自己：“我把cache拿掉后程序还能运行吗？” “cache拿掉前后程序运行的结果一直吗？”。如果答案是否，那您就得重新考虑您的cache方案。我自己就碰到过这样的bug：数据库的有个表里面都 是些配置信息，也就是说是些 读访问远大于写访问 的数据。然后这些数据被理所应当地在程序里面做成内存 cache。问题是有个delete方法删除了一条数据，但是没有更新内存cache。所以读操作的客户代码还是能读到这条数据。问题的根本就是后台数据和cache不一致。

   cache的容量一般相对后台数据量都比较有限。一旦cache满了就势必要选择最没用的数据从cache里面删除掉，为新数据腾出空间。这里就涉及 cahce算法cache algorithm或者叫替换算法。在java的cache产品中一般叫evict policy。下面我们来看一下常用的cache algorithm。

• 最近最少使用算法 Least Recently Used (LRU):

这个算法就是把最近一次使用时间离现在时间最远的数据删除掉。最直观的结构应该是List，采取的算法是：每次访问一个元素后把这个元素放在 List一端，这样一来最远使用的元素自然就被放到List的另一端。每次evict的时候就把那最远使用的元素remove掉。但是现实中常采用的数据 结构是HashMap + List。因为List太慢，List只能提供O(n)的算法，要使得它的add，remove和get的算法为O(1)就必须使用HashMap。最简 单的实现就是利用JDK自带的LinkedHashMap，你可以把它看作普通的HashMap之外，每个元素的key都用链表连接起来从而实现顺序结 构。LinkedHashMap默认的元素顺序是put的顺序，但是如果使用带参数的构造函数，那么LinkedHashMap会根据访问顺序来调整内部 顺序。 LinkedHashMap的get()方法除了返回元素之外还可以把被访问的元素放到链表的底端，这样一来每次顶端的元素就是remove的元素。

• First In, First Out算法

这个比较直观，就是个Queue。但是还是为了保证O(1)的效率，还是要用LinkedHashMap。但是这次使用默认的无参数的构造函数，LinkedHashMap内部使用的是put的顺序。因此每次remove顶端即可。

• 最近最多时用算法Most Recently Used (MRU)

这个算法和LRU是相反操作，所以没什么新鲜的东西。每次remove LinkedHashMap底端的元素就可以实现。

• 使用次数最小算法 Least Frequently Used (LFU)

这 个算法的核心是每次访问元素的时候，这个元素的次数属性加1。所以每次remove操作就是次数属性最小的元素。这次没法用LinkedHashMap来 实现了，因为LinkedHashMap没有接受comparator参数的功能。有些程序是用LinkedList + HashMap来实现。这样add和get操作还是O(1)，只是remove操作的时候先要排序然后再remove，最快也就是O(n*log n)，譬如利用快速排序。或者干脆在remove的时候只是做查找最小元素的算法来除去访问次数最小的元素。

   另外还有其他的cache算法，譬如按照元素自带的过期值expiration和随机random来evict元素的算法。在真正的cache产品中数据结构和算法要比上面描述的要复杂。有些产品自己定义一些数据结构来提高效率，毕竟cache是为了提高效率而产生的。高级的cache产品还可能包括事务机制，JMX和支持cluster环境这样复杂的特性。

   目前比较主流的cache产品有EHCache，OSCache，SwarmCache和JBoss Cache，很多使用Hibernate的人都对都此有些了解。关于JBoss Cache，它在将来可能被JBoss的另外一个叫infinispan 的数据网格平台项目所替代。