Guava Cache源码解析
概述：
本次主要是分析cache的源码，基本概念官方简介即可。
基本类图：
在官方的文档说明中，Guava Cache实现了三种加载缓存的方式：
- LoadingCache在构建缓存的时候，使用build方法内部调用CacheLoader方法加载数据
- 在使用get方法的时候，如果缓存不存在该key或者key过期等，则调用get(K, Callable)方式加载数据；
- 直接调用put方法来放置缓存
核心类及接口的说明，简单的理解如下：
-
Cache接口是Guava对外暴露的缓存接口，对外的方法如下图，Cache定义的接口get接口中，必须要传入Callable，Callable是如果不存在就加载的方式定义，这种就是第二种加载缓存的方式，如果缓存中key不存在或者过期的情况，调用get(K,Callable)来实现
-
LoadingCache是对Cache的进一步封装，继承自Cache接口，主要是实现了get(K)这种定义策略
-
LocalManualCache实际上是Cache的标准实现，注意LocalManualCache不包含无Callable参数的get方法，是一种能在键值找不到的时候手动调用获取值的方式
-
LocalLoadingCache则是LoadingCache的实现，核心的区别在于支持在key找不到的情况下自动加载value的功能点，其实是保存了一个CacheLoading的初始值
-
LocalCache是存储层，是真正意义上数据存放的地方，继承了java.util.AbstractMap同时也实现了ConcurrentMap接口，实现方式和ConcurrentHashMap的实现相同，都是采用分segment来细化管理HashMap中的节点Entry,细粒度锁的方式来增大并发性能。
-
CacheLoader我的理解是缓存加载策略，即负责计算key-value的对应关系，是一个抽象类，需要业务定制自己的策略。在Guava的使用过程中，get参数传入的Callable接口最终会被封装成匿名的CacheLoader，负责加载key到缓存中
-
CacheBuilder 由于cache配置项众多，典型的builder模式场景，复杂对象的构造与其对应配置属性表示的分离。
实现详解:
底层存储LocalCache
LocalCache是线程安全的集合，为了实现这个特性，使用了经典的细粒度锁来控制，本质和ConcurrentHashMap的实现方式类型，在存储中采用了多个Segment对应一个锁，来分散全局锁带来的性能损失。当去put一个entry的时候，一般只需要拥有某一个segment锁就可以完成。下图是ConcurrentHashMap和HashTable存储的描述。
在实现上，LocalCache的并发策略和ConcurrentHashMap的并发策略一致，也是进行了分段，支持不同段的并发写入。
- Segment中使用 volatile AtomicReferenceArray<ReferenceEntry<K, V>> table;
来存储对象，可以这样理解，每一段的Segment相当于一个HashTable的实现 - guava的实例对象中存在一些Queue，这个是Guava扩展实现的各种引用对象回收的策略（Strong、Weak、Soft）类型，这块不具体分析了，平时我并不怎么用Weak、Soft，接触过的只有ThreadLocal里面，这块可以看我博客fail-fast分析。同时，Guava定义了ReferenceEntry,ValueReference也是为GC回收策略做的
- Segment中的table是一个array，每一个元素都是RefenceEntry的链表，同时会将具体的value值封装为一个ValueReference
- LocalCache的扩容是基于Segment的，也就是说是分片的扩展，单个Segment只需要关注自己的容量，与其他的Segment无关的
- Segment中使用的是LRU缓存回收算法，GuavaCache实现的LRU针对的是Segment来做回收的，不是针对整个LocaCache来做的
ReferenceEntry及LRU回收算法的实现
ReferenceEntry是Guava中对一个key-value节点的抽象，每一个Segment中都包含这一个ReferenceEntry数组，每个ReferenceEntry数组项都是一条ReferenceEntry链，其数据结构如下：
类继承结构如下：
ReferenceEntry包装了key-value节点的同时，主要的功能点是增加了引用数据类型回收机制（这个不讨论），设置了accessQueue和writeQueue队列，这个两个其实是双向链表，分别通过previousAccess、nextAccess和previousWrite、nextWrite字段链接而成，这两个队列存在的目的是：实现LRU算法
涉及到一些概念说明：
- accessQueue：这个队列是按照最久未使用的顺序存放的缓存对象（ReferenceEntry）的。由于会经常进行元素的移动，例如把访问过的对象放到队列的最后。
- writeQueue：保存按照写入缓存先后时间的队列,对于新写入的节点或者更新的节点，都会将该节点ReferenceEntry加入到队尾。对头元素是长时间没有变化的对象，而队尾则是最近更新的节点。
- recencyQueue:每次访问操作（即客户端每次调用get方法的时候）都会将该entry加入到队列尾部，并更新accessTime。如果遇到写入操作，则将给队列内容排干，如果accessQueue队列中持有该这些 entry，然后将这些entry add到accessQueue队列。如此看来，recencyQueue是为 accessQueue服务的，一开始也不是很明白为什么有了accessQueue还有设置recencyQueue,下面的链接做了解释，简单讲就是get的使用使用了ConcurrentLinkedQueue来记录访问的数据，这样的好处是不需要lock()
put操作
对于Segment的put，基本流程如下：
- 加锁lock
- 判断缓存是否超过了过期时间
- 判断当前存储是否到了最大容量，如果到了，扩容
- 将新元素进行封装，加入到存储中
- 更新控制队列,accessQueue、writeQueue
- 判断队列中现有元素是否超过了maximumSize，进行容量的控制
- 触发时间通知，包括StatsCounter和RemovalNotification
- 释放锁
Segment对锁的控制
上面提到过LocalCacal对于并发的控制，粒度是Segment级别，而Segment当中锁的操作相对来说比较频繁，在设计的时候，为了简单，直接让Segment继承了java.util.concurrent.locks.ReentrantLock
segment对size的控制策略
guava cache并不会开启额外的线程去扫描当前的存储，看是否达到了存储上限，而是在每次put的时候进行判断
/**
* Performs eviction if the segment is full. This should only be called prior to adding a new
* entry and increasing {@code count}.
*/
@GuardedBy("Segment.this")
void evictEntries() {
if (!map.evictsBySize()) {
return;
}
drainRecencyQueue();
while (totalWeight > maxSegmentWeight) {
ReferenceEntry<K, V> e = getNextEvictable();
if (!removeEntry(e, e.getHash(), RemovalCause.SIZE)) {
throw new AssertionError();
}
}
}
// TODO(fry): instead implement this with an eviction head
ReferenceEntry<K, V> getNextEvictable() {
for (ReferenceEntry<K, V> e : accessQueue) {
int weight = e.getValueReference().getWeight();
if (weight > 0) {
return e;
}
}
throw new AssertionError();
}
之前有说到过accessQueue,这个队列是按照最久未使用的顺序存放的缓存对象（ReferenceEntry）的。由于会经常进行元素的移动，例如把访问过的对象放到队列的最后。而当元素超过了预设的maximumSize,就会从accessQueue的队头取对应的数据，也就是最长时间没有访问到的那个元素，然后从Segment的table中剔除，同样的也要从writeQueue、accessQueue中剔除
ReferenceEntry<K, V> removeValueFromChain(ReferenceEntry<K, V> first,
ReferenceEntry<K, V> entry, @Nullable K key, int hash, ValueReference<K, V> valueReference,
RemovalCause cause) {
enqueueNotification(key, hash, valueReference, cause);
writeQueue.remove(entry);
accessQueue.remove(entry);
if (valueReference.isLoading()) {
valueReference.notifyNewValue(null);
return first;
} else {
return removeEntryFromChain(first, entry);
}
}
Segment对失效时间expireTime的控制
segment对失效时间的控制也并不是由单独的线程去控制，而是在用户每次请求的时候触发检测，这样可以有效的避免不必要的线程消耗。但是这样也会有一定的问题，简单讲，如果大量的请求同时到，而且缓存内容全部都失效的话，相当于没有做任何缓存控制，而且还延长了单次请求的时间。在大促的时候曾经遇到过，每隔一段时间都发现请求rt会出现毛刺，后来发现是用来本地缓存，大量的数据同时失效，而且恰好有很多请求同时来到，全部都去读取DB，rt全部变高。
这种方式也临时的解决方案，比如说，预热缓存的时候分批进行。
如果真的存在一些数据需要常驻本地缓存，可以考虑使用额外的线程进行定时刷新，简单的做法是：假设设置的expireTime为10分钟，那么每隔9分钟，定时任务去读取cache中的数据，然后更新。（之前看zk的代码，zkserver对于client Session的控制是单独线程控制的，那个实现感觉是比较经典的，如果有必要做成是开启额外线程失效的话，可以参考那个实现）。
失效的代码如下，和对数量的控制没大的区别:
void expireEntries(long now) {
drainRecencyQueue();
ReferenceEntry<K, V> e;
while ((e = writeQueue.peek()) != null && map.isExpired(e, now)) {
if (!removeEntry(e, e.getHash(), RemovalCause.EXPIRED)) {
throw new AssertionError();
}
}
while ((e = accessQueue.peek()) != null && map.isExpired(e, now)) {
if (!removeEntry(e, e.getHash(), RemovalCause.EXPIRED)) {
throw new AssertionError();
}
}
}
其他功能点：
StatsCounter和CacheStatus
为了纪录Cache的使用情况，如果命中次数、没有命中次数、evict次数等，Guava Cache中定义了StatsCounter做这些统计信息，它有一个简单的SimpleStatsCounter实现，我们也可以通过CacheBuilder配置自己的StatsCounter。
RemoveListener
put和get操作后都会通知removeListener，默认是同步的方式处理事件通知。也可以通过RemoveListeners将 listener包装成异步方式处理
