我这里说的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):
- 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环境这样复杂的特性。