Guava Cache
内容摘要
- 写入数据到缓存
- 手动写入 (put)
- 自动加载(按需加载)
- 数据清理
- 过期、清理
- 基于容量的清理触发条件
- 基于时间的过期方案
- 基于Reference Key,Value
- 手动移除 (显式移除)
- RemoveListener
- 数据清理时机
- 过期、清理
- refresh
- 配置说明
- 场景说明
1、写数据到缓存
1.1 手动写入 put
Guava Cache 底层是由一个ConcurrentMap实现的,那么底层必然支持两个常规的put:put(k,v), putIfAbsent(k,v)。
从类图上来看,基于Guava Cache实现的cache必然是有一个put(k,v)方法的,直接放k,v对到cache中,并替换掉原有的数据。从接口Cache 来看,只提供了一个put(k,v)方法,底层是一个ConcurrentMap,那么putIfAbsent(k,v)的特性好像被丢弃了。如果你希望使用putIfAbsent,那么可以调用Cache.asMap().putIfAbsent(k,v)。
1.2 自动加载(按需加载)
除了上面的put直接写入cache方式外,Guava Cache还提供了两种实现了get-if-absent-compute语义的方式。
所谓的get-if-absent-compute语义是说:在调用get方法时,如果发现指定的值不存在,则通过加载、计算等方式来提供值。也可以将这个语义理解为lazy load(懒加载、按需加载)。
这两种方式分别为:Cache.get(key, Callable) 、LoadingCache。
Cache.get(key, Callable) 在调用get时,指定一个Callable,如果值不存在时,调用Callable来计算值。计算到值后放入Cache中,并返回结果。
LoadingCache 必须有一个CacheLoader配合一起使用,LoadingCache与CacheLoader的几个方法的调用关系:
LoadingCache.get(k) -> CacheLoader.load(k) LoadingCache.refresh(k) -> CacheLoader.reload(k) LoadingCache.getAll(keys) -> CacheLoader.loadAll(keys) |
CacheLoader是不保证一定可以加载成功,所以它的所有方法都是有异常的。
2、数据清理
任何一种Cache都必须支持一定的Cache清理策略,不然数据会一直增长,内存肯定是扛不住的。Guava Cache也提供了多种Cache清理策略:
2.1 过期、清理
Guava Cache采用基于容量、Soft引用、Weak引用的清理触发条件,基于过期时间、权重来决定哪些数据优先清理,采用LRU算法来清理数据。
2.1.1 基于容量的清理触发条件
如果你的cache数量不应该一直保持增长状态,你需要设定总量来限定cache的容量。可以通过CacheBuilder.maximumSize(long capacity)来限定。当容量即将达到上限时,会自动的进行数据清理。默认的最大容量是 1<<30,如果想要限定,只能设置比1<<30小的数。
因为Guava Cache有默认容量,也就是最大容量的限制,所以任何一个Guava Cache都是有界cache,不会无限制的增加。
在快要达到容量限定值开始清理数据时,采用的是LRU清理算法。与此同时,还可以根据每一个key-value的weight来控制清理,一个key-value的weight越低越容易被清除掉。默认情况下,每一个key-value的weight都是一样的,即为1。当然了你可以自定义weight算法,通过CacheBuilder.weight(weight)即可。
其实严格来讲,这个并不属于
2.1.2 基于时间的过期方案
Guava Cache提供了两种基于时间的数据过期方案:
1) expireAfterWrite()
2) expireAfterAccess()
根据访问后的时间来控制数据是否过期。需要注意的是,设置了基于时间后,不会在内部另外启动线程来定时清理掉过期的数据的。是依赖的与get请求,也就是说每一次访问一个key时,会记录时间,再一次访问时,会先判断数据是否过期了,一旦过期了,就清理掉,被清理掉后,下一次访问时,会调用配置的CacheLoader进行加载。
当使用基于时间的过期策略时,可以自定义自己的计时器的,使用CacheBuilder.ticker(ticker)即可。
需要说明的是,这里的基于时间的过期策略是针对每一个key-value的,如果你的业务中极有可能每一个key-value都不一样的话,就不适合使用了。如果你对业务中有可以枚举的几个时间过期粒度,可以创建多个Guava Cache来完成的。
2.1.3 基于Reference的Key、Value
可以利用weak reference, soft reference来清理缓存。具体来说 weak reference 可以用在key, value上;soft reference 可以用在 value上。
2.1.4 手动移除(显示移除)
当然了,Guava Cache也提供了最基本的手动移除key-value的方案,直接从cache移除:
Cache.invalidate(key) 单个移除
Cache.invalidateAll(keys) 批量移除
Cache.invalidate() 移除所有
2.2 RemoveListener
如果你的业务对数据的清理感兴趣,还可以指定RemoveListener的。
2.3 数据清理时机
从上面的几种清理策略或者过期策略来看,Guava Cache 提供的是被动清理方案,不论是基于容量、基于时间、基于Reference,它们都是被动的清理方案。而手动清理方案虽然是一种主动的清理方案,但它只是针对与你已经确定了不会再用的数据。
Cache.cleanUp() 是一种主动的清理方案,它会清理掉过期的数据。
3、refresh
LoadingCache中的refresh 提供了值替换的功能。在调用refresh时,会先调加载新值,新值加载到后替换掉老值,并返回老值。如果加载不到新值,老值是被保留的,不会被替换掉的。
LoadingCache是引发CacheLoader调用reload方法的,CacheLoader的reload返回的是ListenableFuture,也就表明了,支持同步reload,也支持异步的reload的。
4、配置说明
Guava Cache中的两种cache(Cache,LoadingCache)的实现分别由LocalManuelCache、LocalLoadingCache来完成。创建这两种cache也很简单,使用CacheBuilder即可。在构建cache时,需要配置数据清理策略、并发级别等。
concurrencyLevel:底层的LocalCache 也是一个ConcurrentMap,它的实现与JDK8之前版本中的ConcurrentHashMap类似,也采用了多个segment来提高并发。他们都可以配置concurrencyLevel,来控制segment的数量,来提高并发。ConcurrentHashMap的默认值是16,最大值是1<<16;这里的默认值是4,最大值为 1<<16。
initialCapacity:初始容量配置,默认值是16.
maximumSize:最大容量。
maximumWeight:最大权重
keyEquivalence、valueEquivalence,用于指定内部判断key,value时,是否一样的算法。另外需要说明的是,默认情况下Guava Cache内部判断key, value是否相等时,针对不同的配置采用不同的方案的。如果启用了weakKey,weakValue,softValue的情况下,相应的key或者value的相等性判断是采用的是 ==,如果没有启用weakKey,softValue,weakValue的情况下,相应的key,value的相等性判断使用是equals()。
5、场景说明
不适用于数据有不同的过期时间的场景。
相关文章