为系统引入缓存之前，第一件事情是确认系统是否真的需要缓 存。从开发角度来说，引入缓存会提 高系统复杂度，因为你要考虑缓存的失效、更新、一致性等问题；从运维角度来说，缓存会掩盖一些缺 陷，让问题在更久的时间以后，出现在距离发生现场更远的位置上； 从安全角度来说，缓存可能会泄漏某些保密数据，也是容易受到攻击 的薄弱点。冒着上述种种风险，仍能说服你引入缓存的理由，总结起 来无外乎以下两种。
- 为缓解CPU压力而引入缓存：譬如把方法运行结果存储起来、 把原本要实时计算的内容提前算好、对一些公用的数据进行复用，这 可以节省CPU算力，顺带提升响应性能。
- 为缓解I/O压力而引入缓存：譬如把原本对网络、磁盘等较慢 介质的读写访问变为对内存等较快介质的访问，将原本对单点部件 （如数据库）的读写访问变为对可扩缩部件（如缓存中间件）的访 问，顺带提升响应性能。
请注意，缓存虽然是典型以空间换时间来提升性能的手段，但它 的出发点是缓解CPU和I/O资源在峰值流量下的压力，"顺带"而非 "专门"地提升响应性能。这里的言外之意是如果可以通过增强CPU、 I/O本身的性能（譬如扩展服务器的数量）来满足需要的话，那升级硬 件往往是更好的解决方案，即使需要一些额外的投入成本，也通常要 优于引入缓存后可能带来的风险。
缓存属性
有不少软件系统最初的缓存功能是以HashMap或者 ConcurrentHashMap为起点演进的。当开发人员发现系统中某些资源的 构建成本比较高，而这些资源又有被重复使用的可能时，会很自然地 产生"循环再利用"的想法，将它们放到Map容器中，待下次需要时取 出重用，避免重新构建，这种原始朴素的复用就是最基本的缓存。不 过，一旦我们专门把"缓存"看作一项技术基础设施，一旦它有了通 用、高效、可统计、可管理等方面的需求，其中要考虑的因素就变得 复杂起来。通常，我们设计或者选择缓存至少会考虑以下四个维度的 属性。
- 吞吐量：缓存的吞吐量使用OPS值（每秒操作数，Operation per Second，ops/s）来衡量，反映了对缓存进行并发读、写操作的效率， 即缓存本身的工作效率高低。
- 命中率：缓存的命中率即成功从缓存中返回结果次数与总请求 次数的比值，反映了引入缓存的价值高低，命中率越低，引入缓存的 收益越小，价值越低。
- 扩展功能：即缓存除了基本读写功能外，还提供哪些额外的管 理功能，譬如最大容量、失效时间、失效事件、命中率统计，等等。
- 分布式缓存：缓存可分为"进程内缓存"和"分布式缓存"两 大类，前者只为节点本身提供服务，无网络访问操作，速度快但缓存 的数据不能在各服务节点中共享，后者则相反。
吞吐量
缓存的吞吐量只在并发场景中才有统计的意义，因为若不考虑并 发，即使是最原始的、以HashMap实现的缓存，访问效率也已经是常量 时间复杂度（即O(1)），其中涉及碰撞、扩容等场景的处理属于数据 结构基础，这里不再展开。但HashMap并不是线程安全的容器，如果要 让它在多线程并发下正确地工作，就要用 Collections.synchronizedMap进行包装，这相当于给Map接口的所有 访问方法都自动加全局锁；或者改用ConcurrentHashMap来实现，这相 当于给Map的访问分段加锁（从JDK 8起已取消分段加锁，改为 CAS+Synchronized锁单个元素）。无论采用怎样的实现方法，这些线 程安全措施都会带来一定的吞吐量损失。
命中率与淘汰策略
有限的物理存储决定了任何缓存的容量都不可能是无限的，所以 缓存需要在消耗空间与节约时间之间取得平衡，这要求缓存必须能够 自动或者人工淘汰掉缓存中的低价值数据。考虑到由人工管理的缓存 淘汰主要取决于开发者如何编码，不能一概而论，这里只讨论由缓存 自动进行淘汰的情况。笔者所说的"缓存如何自动地实现淘汰低价值 目标"，现在被称为缓存的淘汰策略。
在了解缓存如何实现自动淘汰低价值数据之前，首先要定义怎样 的数据才算是"低价值"。由于缓存的通用性，这个问题的答案必须 是与具体业务逻辑无关的，只能从缓存工作过程收集到的统计结果来 确定数据是否有价值，通用的统计结果包括但不限于数据何时进入缓 存、被使用过多少次、最近什么时候被使用，等等。一旦确定选择何 种统计数据，就决定了如何通用地、自动地判定缓存中每个数据的价 值高低，也相当于决定了缓存的淘汰策略是如何实现的。目前，最基 础的淘汰策略实现方案有以下三种。
- FIFO（First In First Out）：优先淘汰最早进入被缓存的数据。 FIFO的实现十分简单，但一般来说它并不是优秀的淘汰策略，越是频 繁被用到的数据，往往会越早存入缓存之中。如果采用这种淘汰策 略，很可能会大幅降低缓存的命中率。
- LRU（Least Recent Used）：优先淘汰最久未被访问过的数据。 LRU通常会采用HashMap加LinkedList的双重结构（如LinkedHashMap） 来实现，以HashMap来提供访问接口，保证常量时间复杂度的读取性 能，以LinkedList的链表元素顺序来表示数据的时间顺序，每次缓存命 中时把返回对象调整到LinkedList开头，每次缓存淘汰时从链表末端开 始清理数据。对大多数的缓存场景来说，LRU明显要比FIFO策略合 理，尤其适合用来处理短时间内频繁访问的热点对象。但是如果一些 热点数据在系统中被频繁访问，只是最近一段时间因为某种原因未被 访问过，那么这些热点数据此时就会有被LRU淘汰的风险，换句话 说，LRU依然可能错误淘汰价值更高的数据。
- LFU（Least Frequently Used）：优先淘汰最不经常使用的数据。 LFU会给每个数据添加一个访问计数器，每访问一次就加1，需要淘汰 时就清理计数器数值最小的那批数据。LFU可以解决上面LRU中热点数 据间隔一段时间不访问就被淘汰的问题，但同时它又引入了两个新的 问题。第一个问题是需要对每个缓存的数据专门维护一个计数器，每 次访问都要更新，但这样做会带来高昂的维护开销；另一个问题是不 便于处理随时间变化的热度变化，譬如某个曾经频繁访问的数据现在 不需要了，但很难自动将它清理出缓存。
缓存的淘汰策略直接影响缓存的命中率，没有一种策略是完美 的、能够满足系统全部需求的。不过，随着淘汰算法的不断发展，近 年来的确出现了许多相对性能更好、也更复杂的新算法。以LFU为例， 针对它存在的两个问题，近年来提出的TinyLFU和W-TinyLFU算法就会 有更好的效果。