分布式缓存系列之guava cache

  guava是google的一个开源java框架,其github地址是 https://github.com/google/guava。guava工程包含了若干被Google的 Java项目广泛依赖的核心库,例如:集合 [collections] 、缓存 [caching] 、原生类型支持 [primitives support] 、并发库 [concurrency libraries] 、通用注解 [common annotations] 、字符串处理 [string processing] 、I/O 等等。 所有这些工具每天都在被Google的工程师应用在产品服务中。 其中caching这一块是我常用的模块的之一,今天就来分享一下我对guava cache的一些见解。

   guava cache使用简介

     guava cache 是利用CacheBuilder类用builder模式构造出两种不同的cache加载方式CacheLoader,Callable,共同逻辑都是根据key是加载value。不同的地方在于CacheLoader的定义比较宽泛,是针对整个cache定义的,可以认为是统一的根据key值load value的方法,而Callable的方式较为灵活,允许你在get的时候指定load方法。看以下代码

Cache<String,Object> cache = CacheBuilder.newBuilder()
                .expireAfterWrite(10, TimeUnit.SECONDS).maximumSize(500).build();

         cache.get("key", new Callable<Object>() { //Callable 加载
            @Override
            public Object call() throws Exception {
                return "value";
            }
        });

        LoadingCache<String, Object> loadingCache = CacheBuilder.newBuilder()
                .expireAfterAccess(30, TimeUnit.SECONDS).maximumSize(5)
                .build(new CacheLoader<String, Object>() {
                    @Override
                    public Object load(String key) throws Exception {
                        return "value";
                    }
                });

    这里面有几个参数expireAfterWrite、expireAfterAccess、maximumSize其实这几个定义的都是过期策略。expireAfterWrite适用于一段时间cache可能会发先变化场景。expireAfterAccess是包括expireAfterWrite在内的,因为read和write操作都被定义的access操作。另外expireAfterAccess,expireAfterAccess都是受到maximumSize的限制。当缓存的数量超过了maximumSize时,guava cache会要据LRU算法淘汰掉最近没有写入或访问的数据。这里的maximumSize指的是缓存的个数并不是缓存占据内存的大小。 如果想限制缓存占据内存的大小可以配置maximumWeight参数。

      看代码:

  CacheBuilder.newBuilder().weigher(new Weigher<String, Object>() {

              @Override
              public int weigh(String key, Object value) {
                  return 0;  //the value.size()
              }
          }).expireAfterWrite(10, TimeUnit.SECONDS).maximumWeight(500).build();

   weigher返回每个cache value占据内存的大小,这个大小是由使用者自身定义的,并且put进内存时就已经确定后面就再不会发生变动。maximumWeight定义了所有cache value加起的weigher的总和不能超过的上限。

    注意一点就是maximumWeight与maximumSize两者只能生效一个是不能同时使用的!

   guava cache的设计

guava cache作为一个被广泛使用的缓存组件,设计上它有哪些过人之处?

    先看下cache的类实现定义

class LocalCache<K, V> extends AbstractMap<K, V> implements ConcurrentMap<K, V> {....} 

    我们看到了ConcurrentMap,所以我们知道了一点guava cache基于ConcurrentHashMap的基础上设计。所以ConcurrentHashMap的优点它也具备。既然实现了      ConcurrentMap那再看下guava cache中的Segment的实现是怎样?

 我们看到guava cache 中的Segment本质是一个ReentrantLock。内部定义了table,wirteQueue,accessQueue定义属性。其中table是一个ReferenceEntry原子类数组,里面就存放了cache的内容。wirteQueue存放的是对table的写记录,accessQueue是访问记录。guava cache的expireAfterWrite,expireAfterAccess就是借助这个两个queue来实现的。

  了解了guava cache的大概存储结构,下面看通过对cache的操作来进行更深入的了解。

   put(key,val)操作。

  public V put(K key, V value) {
    checkNotNull(key);
    checkNotNull(value);
    int hash = hash(key);
    return segmentFor(hash).put(key, hash, value, false);
  }

  设置缓存大概的过程:根据key 哈希到对应的segment,然后对segment加锁lock(),然后获取segment.table对应的结点

int index = hash & (table.length() - 1);
ReferenceEntry<K, V> first = table.get(index);

  之后入队的过程和hashMap的入队过程类似。入队完之后还会进行相关操作比如更新accessQueue和wiriteQueue,累加totalWeight

 void recordWrite(ReferenceEntry<K, V> entry, int weight, long now) {
      // we are already under lock, so drain the recency queue immediately
      drainRecencyQueue();
      totalWeight += weight;

      if (map.recordsAccess()) {
        entry.setAccessTime(now);
      }
      if (map.recordsWrite()) {
        entry.setWriteTime(now);
      }
      accessQueue.add(entry);
      writeQueue.add(entry);
    }

  get(key)操作 。

     第一步也是先定位到所在segment

V get(K key, CacheLoader<? super K, V> loader) throws ExecutionException {
    int hash = hash(checkNotNull(key));
    return segmentFor(hash).get(key, hash, loader);
  }

   判断key对应的ReferenceEntry存在

  ReferenceEntry<K, V> e = getEntry(key, hash);
          if (e != null) {
            long now = map.ticker.read();
            V value = getLiveValue(e, now);
            if (value != null) {
              recordRead(e, now);
              statsCounter.recordHits(1);
              return scheduleRefresh(e, key, hash, value, now, loader);
            }
            ValueReference<K, V> valueReference = e.getValueReference();
            if (valueReference.isLoading()) {
              return waitForLoadingValue(e, key, valueReference);
            }
          }
getLiveValue(e, now)如果返回了null就表示当前cache已经过期了,不为null时recordRead(e, now)记录最新访问时间为now,然后统计命中率。scheduleRefresh(e, key, hash, value, now, loader)相当于一个双重检查,再次检查cache有没有过期或者有不有其它线程在更新。如果都没有旧返回拿原值返回,有则调用loader方法去获取最新的值然后返回。这时注意如果是loadingCache,并且valueReference.isLoading()为true的时候就表示有其它线程正在更新该cache,其它所有线程都要wait到这个线程loading完才能返回。

key对应的ReferenceEntry不存在:缓存没有加载进来或者已经被remove掉。
      return lockedGetOrLoad(key, hash, loader);

  lockedGetOrLoad执行逻辑是先加锁lock(),判断当前是否有其它线程在loading该cache,如果有等待其加载完毕然后返回。否自己执行loader把值设进cache中然后返回。   

try {
          // Synchronizes on the entry to allow failing fast when a recursive load is
          // detected. This may be circumvented when an entry is copied, but will fail fast most
          // of the time.
          synchronized (e) {
            return loadSync(key, hash, loadingValueReference, loader);
          }
        } finally {
          statsCounter.recordMisses(1);
        }

  

    guava cache的淘汰策略

     guava cache总体来说有四种淘汰策略。

     1、size-based 基本于使用量。

      当缓存个数超过CacheBuilder.maximumSize(long)设置的值时,优先淘汰最近没有使用或者不常用的元素。同理CacheBuilder.maximumWeight(long)也是一样逻辑。

     2、timed eviction 基于时间驱逐。

       expireAfterAccess(long, TimeUnit)仅在指定上一次读/更新操作过了指定持续时间之后才考虑淘汰,淘汰逻辑与size-based是类似的。优先淘汰最近没有使用或者不常用的元素

     expireAfterWrite(long, TimeUnit) 仅在指定上一次写/更新操作过了指定持续时间之后才考虑淘汰,淘汰逻辑与size-based是类似的。优先淘汰最近没有使用或者不常用的元素

    3、Reference-based Eviction 基本于引用驱逐

        在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Refernce)、虚引用(Phantom Reference)。四种引用强度依次减弱。这四种引用除了强引用(Strong Reference)之外,其它的引用所对应的对象来JVM进行GC时都是可以确保被回收的。所以通过使用弱引用的键、或弱引用的值、或软引用的值,Guava Cache可以把缓存设置为允许垃圾回收:

  • CacheBuilder.weakKeys():使用弱引用存储键。当键没有其它(强或软)引用时,缓存项可以被垃圾回收。因为垃圾回收仅依赖恒等式(==),使用弱引用键的缓存用==而不是equals比较键。
  • CacheBuilder.weakValues():使用弱引用存储值。当值没有其它(强或软)引用时,缓存项可以被垃圾回收。因为垃圾回收仅依赖恒等式(==),使用弱引用值的缓存用==而不是equals比较值。
  • CacheBuilder.softValues():使用软引用存储值。软引用只有在响应内存需要时,才按照全局最近最少使用的顺序回收。考虑到使用软引用的性能影响,我们通常建议使用更有性能预测性的缓存大小限定(使用软引用值的缓存同样用==而不是equals比较值)

        这样的好处就是当内存资源紧张时可以释放掉到缓存的内存。注意!CacheBuilder如果没有指明默认是强引用的,GC时如果没有元素到达指定的过期时间,内存是不能被回收的。

   4、显示删除

   任何时候,你都可以显式地清除缓存项,而不是等到它被回收:

       提一下guava cache 是怎么触发元素回收的。guava的元素回收与其它的一些框架不一样比如redis,redis是起额外的线程去回收元素。而guava是进行get,put操作的时候顺便把元素回收的。这样比一般的缓存另起线程监控清理相比,可以减少开销,但如果长时间没有调用方法的话,会导致不能及时的清理释放内存空间的问题。回收时主要处理四个Queue:1. keyReferenceQueue;2. valueReferenceQueue;3. writeQueue;4. accessQueue。前两个queue是因为WeakReference、SoftReference被垃圾回收时加入的,清理时只需要遍历整个queue,将对应的项从LocalCache中移除即可,这里keyReferenceQueue存放ReferenceEntry,而valueReferenceQueue存放的是ValueReference。而对后面两个Queue,只需要检查是否配置了相应的expire时间,然后从头开始查找已经expire的Entry,将它们移除即可。

     总的来说,guava cache基于ConcurrentHashMap的优秀设计借鉴,在高并发场景支持线程安全,使用Reference引用命令,保证了GC的可回收到相应的数据,有效节省空间;同时write链和access链的设计,能更灵活、高效的实现多种类型的缓存清理策略,包括基于容量的清理、基于时间的清理、基于引用的清理等;

原文地址:https://www.cnblogs.com/linlinismine/p/9349343.html

时间: 2024-10-03 03:52:51

分布式缓存系列之guava cache的相关文章

【分布式缓存系列】集群环境下Redis分布式锁的正确姿势

一.前言 在上一篇文章中,已经介绍了基于Redis实现分布式锁的正确姿势,但是上篇文章存在一定的缺陷——它加锁只作用在一个Redis节点上,如果通过sentinel保证高可用,如果master节点由于某些原因发生了主从切换,那么就会出现锁丢失的情况: 客户端1在Redis的master节点上拿到了锁 Master宕机了,存储锁的key还没有来得及同步到Slave上 master故障,发生故障转移,slave节点升级为master节点 客户端2从新的Master获取到了对应同一个资源的锁 于是,客

什么是分布式缓存?

缓存这种能够提升指令和数据读取速度的特性,随着本地计算机系统向分布式系统的扩展,在分布式计算领域中得到了广泛的应用,称为分布式缓存. 中文名 分布式缓存 外文名 Distribute Cache 简介 分布式缓存能够处理大量的动态数据,因此比较适合应用在Web 2.0时代中的社交网站等需要由用户生成内容的场景.从本地缓存扩展到分布式缓存后,关注重点从CPU.内存.缓存之间的数据传输速度差异也扩展到了业务系统.数据库.分布式缓存之间的数据传输速度差异. 业务系统.数据库.分布式缓存之间的数据流 图

Java 高并发缓存与Guava Cache

一.背景 缓存是我们在开发中为了提高系统的性能,把经常的访问业务的数据第一次把处理结果先放到缓存中,第二次就不用在对相同的业务数据在重新处理一遍,这样就提高了系统的性能.缓存分好几种: (1)本地缓存. (2)数据库缓存. (3)分布式缓存. 分布式缓存比较常用的有memcached等,memcached是高性能的分布式内存缓存服务器,缓存业务处理结果,减少数据库访问次数和相同复杂逻辑处理的时间,以提高动态Web应用的速度. 提高可扩展性. 二.本地缓存在高并发下的问题以及解决 今天我们介绍的是

缓存框架Guava Cache部分源码分析

在本地缓存中,最常用的就是OSCache和谷歌的Guava Cache.其中OSCache在07年就停止维护了,但它仍然被广泛的使用.谷歌的Guava Cache也是一个非常优秀的本地缓存,使用起来非常灵活,功能也十分强大,可以说是当前本地缓存中最优秀的缓存框架之一.之前我们分析了OSCache的部分源码,本篇就通过Guava Cache的部分源码,来分析一下Guava Cache的实现原理. 在分析之前,先弄清数据结构的使用.之前的文章提到,OSCache使用了一个扩展的HashTable,作

第二章 Google guava cache源码解析1--构建缓存器

1.guava cache 当下最常用最简单的本地缓存 线程安全的本地缓存 类似于ConcurrentHashMap(或者说成就是一个ConcurrentHashMap,只是在其上多添加了一些功能) 2.使用实例 具体在实际中使用的例子,去查看<第七章 企业项目开发--本地缓存guava cache>,下面只列出测试实例: import java.util.concurrent.ExecutionException; import java.util.concurrent.TimeUnit;

[.NET领域驱动设计实战系列]专题八:DDD案例:网上书店分布式消息队列和分布式缓存的实现

一.引言 在上一专题中,商家发货和用户确认收货功能引入了消息队列来实现的,引入消息队列的好处可以保证消息的顺序处理,并且具有良好的可扩展性.但是上一专题消息队列是基于内存中队列对象来实现,这样实现有一个弊端,就是一旦服务重启或出现故障时,此时消息队列中的消息会丢失,并且也记录不了日志.所以就会出现,商家发货成功后,用户并没有收到邮件通知,并且也没有日志让我们发现是否发送了邮件通知.为了解决这个问题,就需要引入一种可恢复的消息队列.目前有很多开源的消息队列都支持可恢复的,例如TibcoEms.ne

Spark源码系列(五)RDD是如何被分布式缓存?

这一章想讲一下Spark的缓存是如何实现的.这个persist方法是在RDD里面的,所以我们直接打开RDD这个类. def persist(newLevel: StorageLevel): this.type = { // StorageLevel不能随意更改 if (storageLevel != StorageLevel.NONE && newLevel != storageLevel) { throw new UnsupportedOperationException("C

spring boot guava cache 缓存学习

http://blog.csdn.net/hy245120020/article/details/78065676 ************************************************************ spring boot guava cache 缓存学习 自定义key 自定义全局key过期时间,缓存个数 针对单个key自定义过期时间,缓存个数 引入依赖 <dependency> <groupId>org.springframework.boo

分布式架构系列:缓存

一.缓存概述 缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题.提供高性能的数据快速访问. 1.1缓存的原理 (1) 将数据写入/读取速度更快的存储(设备): (2) 将数据缓存到离应用最近的位置: (3) 将数据缓存到离用户最近的位置. 1.2缓存分类 在分布式系统中,缓存的应用非常广泛,从部署角度有以下几个方面的缓存应用. (1) CDN缓存: (2) 反向代理缓存: (3) 分布式Cache: (4) 本地应用缓存: 1.3缓存媒介 常用中间件:Varni