Java Cache系列之Guava Cache

Guava作为Google开源出来的工具库，Google自己对Guava的描述：The Guava project contains several of Google's core libraries that we rely on in our Java-based projects: collections, caching, primitives support, concurrency libraries, common annotations, string processing, I/O, and so forth.作为Google的core libraries，直接提供Cache实现，足以证明Cache应用的广泛程度。 然而作为工具库中的一部分，我们自然不能期待Guava对Cache有比较完善的实现。因而Guava中的Cache只能用于一些把Cache作为一种辅助设计的项目或者在项目的前期为了实现简单而引入。

在Guava CacheBuilder的注释中给定Guava Cache以下的需求：

1. automatic loading of entries into the cache
2. least-recently-used eviction when a maximum size is exceeded
3. time-based expiration of entries, measured since last access or last write
4. keys automatically wrapped in WeakReference
5. values automatically wrapped in WeakReference or SoftReference soft
6. notification of evicted (or otherwise removed) entries
7. accumulation of cache access statistics

对于这样的需求，如果要我们自己来实现，我们应该怎么设计？对于我来说，对于其核心实现我会做如下的设计：

1. 定义一个CacheConfig类用于纪录所有的配置，如CacheLoader，maximum size、expire time、key reference level、value reference level、eviction listener等。
2. 定义一个Cache接口，该接口类似Map（或ConcurrentMap），但是为了和Map区别开来，因而重新定义一个Cache接口。
3. 定义一个实现Cache接口的类CacheImpl，它接收CacheConfig作为参数的构造函数，并将CacheConfig实例保存在字段中。
4. 在实现上模仿ConcurrentHashMap的实现方式，有一个Segment数组，其长度由配置的concurrencyLevel值决定。为了实现最近最少使用算法（LRU），添加AccessQueue和WriteQueue字段，这两个Queue内部采用双链表，每次新创建一个Entry，就将这个Entry加入到这两个Queue的末尾，而每读取一个Entry就将其添加到AccessQueue的末尾，没更新一个Entry将该Entry添加到WriteQueue末尾。为了实现key和value上的WeakReference、SoftReference，添加ReferenceQueue类型的keyReferenceQueue和valueReferenceQueue字段。
5. 在每次调用方法之前都遍历AccessQueue和WriteQueue，如果发现有Entry已经expire，就将该Entry从这两个Queue上和Cache中移除。然后遍历keyReferenceQueue和valueReference，如果发现有项存在，同样将它们移除。在移除时如果有EvictionListener注册着，则调用该listener。
6. 对Segment实现，它时一个CacheEntry数组，CacheEntry是一个链节点，它包含hash、key、vlaue、next。CacheEntry根据是否需要包装在WeakReference中创建WeakEntry或StrongEntry，而对value根据是否需要包装在WeakReference、SoftReference中创建WeakValueReference、SoftValueReference、StrongValueReference。在get操作中对于需要使用CacheLoader加载的值先添加一个具有LoadingValueReference值的Entry，这样可以保证同一个Key只加载依次。在加载成功后将LoadingValueReference根据配置替换成其他Weak、Soft、Strong ValueReference。
   
7. 对于cache access statistics，只需要有一个类在需要的地方做一些统计计数即可。
8. 最后我必须得承认以上的设计有很多是对Guava Cache的参考，我有点后悔没有在看源码之前考虑这个问题，等看过以后思路就被它的实现给羁绊了。。。。

Guava Cache的数据结构
因为新进一家公司，要熟悉新公司项目以及项目用到的第三方库的代码，因而几个月来看了许多代码。然后越来越发现要理解一个项目的最快方法是先搞清楚该项目的底层数据结构，然后再去看构建于这些数据结构以上的逻辑就会容易许多。记得在还是学生的时候，有在一本书上看到过一个大牛说的一句话：程序＝数据结构＋算法；当时对这句话并不是和理解，现在是很赞同这句话，我对算法接触的不多，因而我更倾向于将这里的算法理解长控制数据流动的逻辑。因而我们先来熟悉一下Guava Cache的数据结构。

Cache类似于Map，它是存储键值对的集合，然而它和Map不同的是它还需要处理evict、expire、dynamic load等逻辑，需要一些额外信息来实现这些操作。在面向对象思想中，经常使用类对一些关联性比较强的数据做封装，同时把操作这些数据相关的操作放到该类中。因而Guava Cache使用ReferenceEntry接口来封装一个键值对，而用ValueReference来封装Value值。这里之所以用Reference命令，是因为Guava Cache要支持WeakReference Key和SoftReference、WeakReference value。

ValueReference
对于ValueReference，因为Guava Cache支持强引用的Value、SoftReference Value以及WeakReference Value，因而它对应三个实现类：StrongValueReference、SoftValueReference、WeakValueReference。为了支持动态加载机制，它还有一个LoadingValueReference，在需要动态加载一个key的值时，先把该值封装在LoadingValueReference中，以表达该key对应的值已经在加载了，如果其他线程也要查询该key对应的值，就能得到该引用，并且等待改值加载完成，从而保证该值只被加载一次（可以在evict以后重新加载）。在该只加载完成后，将LoadingValueReference替换成其他ValueReference类型。对新创建的LoadingValueReference，由于其内部oldValue的初始值是UNSET，它isActive为false，isLoading为false，因而此时的LoadingValueReference的isActive为false，但是isLoading为true。每个ValueReference都纪录了weight值，所谓weight从字面上理解是“该值的重量”，它由Weighter接口计算而得。weight在Guava Cache中由两个用途：1. 对weight值为0时，在计算因为size limit而evict是忽略该Entry（它可以通过其他机制evict）；2. 如果设置了maximumWeight值，则当Cache中weight和超过了该值时，就会引起evict操作。但是目前还不知道这个设计的用途。最后，Guava Cache还定义了Stength枚举类型作为ValueReference的factory类，它有三个枚举值：Strong、Soft、Weak，这三个枚举值分别创建各自的ValueReference，并且根据传入的weight值是否为1而决定是否要创建Weight版本的ValueReference。以下是ValueReference的类图： 
 
这里ValueReference之所以要有对ReferenceEntry的引用是因为在Value因为WeakReference、SoftReference被回收时，需要使用其key将对应的项从Segment的table中移除；copyFor()函数的存在是因为在expand(rehash)重新创建节点时，对WeakReference、SoftReference需要重新创建实例（个人感觉是为了保持对象状态不会相互影响，但是不确定是否还有其他原因），而对强引用来说，直接使用原来的值即可，这里很好的展示了对彼变化的封装思想；notifiyNewValue只用于LoadingValueReference，它的存在是为了对LoadingValueReference来说能更加及时的得到CacheLoader加载的值。

ReferenceEntry
ReferenceEntry是Guava Cache中对一个键值对节点的抽象。和ConcurrentHashMap一样，Guava Cache由多个Segment组成，而每个Segment包含一个ReferenceEntry数组，每个ReferenceEntry数组项都是一条ReferenceEntry链。并且一个ReferenceEntry包含key、hash、valueReference、next字段。除了在ReferenceEntry数组项中组成的链，在一个Segment中，所有ReferenceEntry还组成access链（accessQueue）和write链（writeQueue），这两条都是双向链表，分别通过previousAccess、nextAccess和previousWrite、nextWrite字段链接而成。在对每个节点的更新操作都会将该节点重新链到write链和access链末尾，并且更新其writeTime和accessTime字段，而没找到一个节点，都会将该节点重新链到access链末尾，并更新其accessTime字段。这两个双向链表的存在都是为了实现采用最近最少使用算法（LRU）的evict操作（expire、size limit引起的evict）。

Guava Cache中的ReferenceEntry可以是强引用类型的key，也可以WeakReference类型的key，为了减少内存使用量，还可以根据是否配置了expireAfterWrite、expireAfterAccess、maximumSize来决定是否需要write链和access链确定要创建的具体Reference：StrongEntry、StrongWriteEntry、StrongAccessEntry、StrongWriteAccessEntry等。创建不同类型的ReferenceEntry由其枚举工厂类EntryFactory来实现，它根据key的Strongth类型、是否使用accessQueue、是否使用writeQueue来决定不同的EntryFactry实例，并通过它创建相应的ReferenceEntry实例。ReferenceEntry类图如下： 

WriteQueue和AccessQueue 
为了实现最近最少使用算法，Guava Cache在Segment中添加了两条链：write链（writeQueue）和access链（accessQueue），这两条链都是一个双向链表，通过ReferenceEntry中的previousInWriteQueue、nextInWriteQueue和previousInAccessQueue、nextInAccessQueue链接而成，但是以Queue的形式表达。WriteQueue和AccessQueue都是自定义了offer、add（直接调用offer）、remove、poll等操作的逻辑，对于offer（add）操作，如果是新加的节点，则直接加入到该链的结尾，如果是已存在的节点，则将该节点链接的链尾；对remove操作，直接从该链中移除该节点；对poll操作，将头节点的下一个节点移除，并返回。

   static  final  class WriteQueue  extends AbstractQueue> {
     final ReferenceEntry head =  new AbstractReferenceEntry() ....
    @Override
     public  boolean offer(ReferenceEntry entry) {
       //  unlink
      connectWriteOrder(entry.getPreviousInWriteQueue(), entry.getNextInWriteQueue());
       //  add to tail
      connectWriteOrder(head.getPreviousInWriteQueue(), entry);
      connectWriteOrder(entry, head);
       return  true;
    }
    @Override
     public ReferenceEntry peek() {
      ReferenceEntry next = head.getNextInWriteQueue();
       return (next == head) ?  null : next;
    }
    @Override
     public ReferenceEntry poll() {
      ReferenceEntry next = head.getNextInWriteQueue();
       if (next == head) {
         return  null;
      }
      remove(next);
       return next;
    }
    @Override
     public  boolean remove(Object o) {
      ReferenceEntry e = (ReferenceEntry) o;
      ReferenceEntry previous = e.getPreviousInWriteQueue();
      ReferenceEntry next = e.getNextInWriteQueue();
      connectWriteOrder(previous, next);
      nullifyWriteOrder(e);
       return next != NullEntry.INSTANCE;
    }
    @Override
     public  boolean contains(Object o) {
      ReferenceEntry e = (ReferenceEntry) o;
       return e.getNextInWriteQueue() != NullEntry.INSTANCE;
    }
....
  }

对于不需要维护WriteQueue和AccessQueue的配置（即没有expire time或size limit的evict策略）来说，我们可以使用DISCARDING_QUEUE以节省内存： 

   static  final Queueextends Object> DISCARDING_QUEUE =  new AbstractQueue