sever 2008 网站建设,做本地网站,石家庄做外贸网站建设,二级建造师注册查询系统缓存Caffine Caffine介绍添加手动加载自动加载异步加载 驱逐基于容量基于时间基于引用 移除显式移除移除监听器 刷新计算Interner规范 Caffine介绍
Caffeine是一个基于Java8开发的提供了近乎最佳命中率的高性能的缓存库。
缓存和ConcurrentMap有点相似#xff0c;但还是有… 缓存Caffine Caffine介绍添加手动加载自动加载异步加载 驱逐基于容量基于时间基于引用 移除显式移除移除监听器 刷新计算Interner规范 Caffine介绍
Caffeine是一个基于Java8开发的提供了近乎最佳命中率的高性能的缓存库。
缓存和ConcurrentMap有点相似但还是有所区别。最根本的区别是ConcurrentMap将会持有所有加入到缓存当中的元素直到它们被从缓存当中手动移除。但是Caffeine的缓存Cache 通常会被配置成自动驱逐缓存中元素以限制其内存占用。在某些场景下LoadingCache和AsyncLoadingCache 因为其自动加载缓存的能力将会变得非常实用。
Caffeine提供了灵活的构造器去创建一个拥有下列特性的缓存
自动加载元素到缓存当中异步加载的方式也可供选择当达到最大容量的时候可以使用基于就近度和频率的算法进行基于容量的驱逐将根据缓存中的元素上一次访问或者被修改的时间进行基于过期时间的驱逐当向缓存中一个已经过时的元素进行访问的时候将会进行异步刷新key将自动被弱引用所封装value将自动被弱引用或者软引用所封装驱逐(或移除)缓存中的元素时将会进行通知写入传播到一个外部数据源当中持续计算缓存的访问统计指标
添加
Caffeine提供了四种缓存添加策略手动加载自动加载手动异步加载和自动异步加载。
手动加载
Testpublic void shoudong() {CacheObject, Object cache Caffeine.newBuilder().expireAfterAccess(10, TimeUnit.SECONDS).maximumSize(10_000).build();String key 1;//查找一个缓存元素没有查找到的时候返回nullObject ifPresent cache.getIfPresent(key);System.out.println(ifPresent); //null//查询缓存如果缓存不存在则进行计算并缓存(建议使用)Object o cache.get(key, k - k aaa);System.out.println(o);//1aaaObject ifPresent1 cache.getIfPresent(key);System.out.println(ifPresent1);//1aaa//缓存cache.put(2,b);Object ifPresent2 cache.getIfPresent(2);System.out.println(ifPresent2 ifPresent2);//ifPresent2 b//移除一个缓存元素cache.invalidate(2);System.out.println(cache.getIfPresent(2));//null}推荐使用 cache.get(key, k - value) 操作来在缓存中不存在该key对应的缓存元素的时候进行计算生成并直接写入至缓存内而当该key对应的缓存元素存在的时候将会直接返回存在的缓存值。
自动加载
相当于在build中添加查询缓存不存在时的备选方案
Testpublic void zidong() {LoadingCacheObject, Object cache Caffeine.newBuilder().expireAfterAccess(10, TimeUnit.SECONDS).maximumSize(10_000).build(key - key bbb);//当不存在时构建并缓存String key 11;System.out.println(cache.get(key));//11bbbMapObject, Object all cache.getAll(List.of(11));System.out.println(all);//{1111bbb}}注意此处build返回的是LoadingCache,LoadingCahce需要在build中传入CacheLoader。 通过 getAll可以达到批量查找缓存的目的。 默认情况下在getAll 方法中将会对每个不存在对应缓存的key调用一次 CacheLoader.load 来生成缓存元素。 在批量检索比单个查找更有效率的场景下你可以覆盖并开发CacheLoader.loadAll 方法来使你的缓存更有效率。 值得注意的是你可以通过实现一个 CacheLoader.loadAll并在其中为没有在参数中请求的key也生成对应的缓存元素。打个比方如果对应某个key生成的缓存元素与包含这个key的一组集合剩余的key所对应的元素一致那么在loadAll中也可以同时加载剩下的key对应的元素到缓存当中。
异步加载
https://github.com/ben-manes/caffeine/wiki/Population-zh-CN
驱逐
Caffeine 提供了三种驱逐策略分别是基于容量基于时间和基于引用三种类型。
基于容量
public void rongliang(){// 基于缓存内的元素个数进行驱逐LoadingCacheObject, String rongliang Caffeine.newBuilder().maximumSize(10_000).build(key - key aa);// 基于缓存内元素权重进行驱逐LoadingCacheObject, String quanzhong Caffeine.newBuilder().maximumWeight(10_000).weigher(Objects::hash).build(key - key aa);}如果你的缓存容量不希望超过某个特定的大小那么记得使用Caffeine.maximumSize(long)。缓存将会尝试通过基于就近度和频率的算法来驱逐掉不会再被使用到的元素。 另一种情况你的缓存可能中的元素可能存在不同的“权重”–打个比方你的缓存中的元素可能有不同的内存占用–你也许需要借助Caffeine.weigher(Weigher) 方法来界定每个元素的权重并通过 Caffeine.maximumWeight(long)方法来界定缓存中元素的总权重来实现上述的场景。除了“最大容量”所需要的注意事项在基于权重驱逐的策略下一个缓存元素的权重计算是在其创建和更新时此后其权重值都是静态存在的在两个元素之间进行权重的比较的时候并不会根据进行相对权重的比较。
基于时间
// 基于固定的过期时间驱逐策略
LoadingCacheKey, Graph graphs Caffeine.newBuilder().expireAfterAccess(5, TimeUnit.MINUTES).build(key - createExpensiveGraph(key));
LoadingCacheKey, Graph graphs Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES).build(key - createExpensiveGraph(key));// 基于不同的过期驱逐策略
LoadingCacheKey, Graph graphs Caffeine.newBuilder().expireAfter(new ExpiryKey, Graph() {public long expireAfterCreate(Key key, Graph graph, long currentTime) {// Use wall clock time, rather than nanotime, if from an external resourcelong seconds graph.creationDate().plusHours(5).minus(System.currentTimeMillis(), MILLIS).toEpochSecond();return TimeUnit.SECONDS.toNanos(seconds);}public long expireAfterUpdate(Key key, Graph graph, long currentTime, long currentDuration) {return currentDuration;}public long expireAfterRead(Key key, Graph graph,long currentTime, long currentDuration) {return currentDuration;}}).build(key - createExpensiveGraph(key));Caffeine提供了三种方法进行基于时间的驱逐:
expireAfterAccess(long, TimeUnit): 一个元素在上一次读写操作后一段时间之后在指定的时间后没有被再次访问将会被认定为过期项。在当被缓存的元素时被绑定在一个session上时当session因为不活跃而使元素过期的情况下这是理想的选择。一般用于缓存expireAfterWrite(long, TimeUnit): 一个元素将会在其创建或者最近一次被更新之后的一段时间后被认定为过期项。在对被缓存的元素的时效性存在要求的场景下这是理想的选择。一般用于监控状态对于时效性比较高expireAfter(Expiry): 一个元素将会在指定的时间后被认定为过期项。当被缓存的元素过期时间收到外部资源影响的时候(用到实体类内部时间属性)这是理想的选择。
在写操作和偶尔的读操作中将会进行周期性的过期事件的执行。过期事件的调度和触发将会在O(1)的时间复杂度内完成。默认情况下过期时间需要读写操作如果没有读写操作过期时间不会执行 为了使过期更有效率可以通过在你的Cache构造器中通过Scheduler接口和Caffeine.scheduler(Scheduler) 方法去指定一个调度线程代替在缓存活动中去对过期事件进行调度。使用Java 9以上版本的用户可以选择Scheduler.systemScheduler()利用系统范围内的调度线程。
基于引用
// 当key和缓存元素都不再存在其他强引用的时候驱逐
LoadingCacheKey, Graph graphs Caffeine.newBuilder().weakKeys().weakValues().build(key - createExpensiveGraph(key));// 当进行GC的时候进行驱逐
LoadingCacheKey, Graph graphs Caffeine.newBuilder().softValues().build(key - createExpensiveGraph(key));Caffeine 允许你配置你的缓存去让GC去帮助清理缓存当中的元素其中key支持弱引用而value则支持弱引用和软引用。记住 AsyncCache不支持软引用和弱引用。 Caffeine.weakKeys() 在保存key的时候将会进行弱引用。这允许在GC的过程中当key没有被任何强引用指向的时候去将缓存元素回收。由于GC只依赖于引用相等性。这导致在这个情况下缓存将会通过引用相等( )而不是对象相等 equals()去进行key之间的比较。 Caffeine.weakValues()在保存value的时候将会使用弱引用。这允许在GC的过程中当value没有被任何强引用指向的时候去将缓存元素回收。由于GC只依赖于引用相等性。这导致在这个情况下缓存将会通过引用相等()而不是对象相等 equals()去进行value之间的比较。 Caffeine.softValues()在保存value的时候将会使用软引用。为了相应内存的需要在GC过程中被软引用的对象将会被通过LRU算法回收。由于使用软引用可能会影响整体性能我们还是建议通过使用基于缓存容量的驱逐策略代替软引用的使用。同样的使用 softValues() 将会通过引用相等()而不是对象相等 equals()去进行value之间的比较。
移除
术语:
驱逐 缓存元素因为策略被移除失效 缓存元素被手动移除移除 由于驱逐或者失效而最终导致的结果
显式移除
在任何时候你都可以手动去让某个缓存元素失效而不是只能等待其因为策略而被驱逐。
// 失效key
cache.invalidate(key)
// 批量失效key
cache.invalidateAll(keys)
// 失效所有的key
cache.invalidateAll()移除监听器
Testpublic void removeListener() throws InterruptedException, IOException {CacheObject, Object cache Caffeine.newBuilder()
// .maximumSize(10_000).expireAfterAccess(5, TimeUnit.SECONDS).scheduler(Scheduler.systemScheduler())//定义执行移除任务的Scheduler.removalListener((k, v, cause) - {System.out.println(k k);System.out.println(v v);System.out.println(cause.wasEvicted() cause.wasEvicted());}).evictionListener((k, v, cause) - {System.out.println(eviction k k);System.out.println(eviction v v);System.out.println(eviction cause.wasEvicted() cause.wasEvicted());}).build();cache.put(1,a);cache.put(2,b);cache.put(3,b);cache.invalidate(1);TimeUnit.SECONDS.sleep(10);System.out.println(cache.getIfPresent(\2\) cache.getIfPresent(2));//只有获取值的时候才进行过期操作}
k 1
v a
cause.wasEvicted() false
cache.getIfPresent(2) null
eviction k 2
eviction v b
eviction cause.wasEvicted() true
eviction k 3
eviction v b
eviction cause.wasEvicted() true
k 3
v b
cause.wasEvicted() true
k 2
v b
cause.wasEvicted() true你可以为你的缓存通过Caffeine.removalListener(RemovalListener)方法定义一个移除监听器在一个元素被移除失效和驱逐的时候进行相应的操作。这些操作是使用 Executor 异步执行的其中默认的 Executor 实现是ForkJoinPool.commonPool() 并且可以通过覆盖Caffeine.executor(Executor)方法自定义线程池的实现。 当元素被驱逐时根据各种策略 你需要使用 Caffeine.evictionListener(RemovalListener) 。这个监听器将在 RemovalCause.wasEvicted() 为 true代表被驱逐 的时候被触发。为了移除操作能够明确生效 Cache.asMap() 提供了方法来执行原子操作。
刷新
一般用于一段时间把数据库中的数据刷新到缓存中保证缓存和数据库的数据一致性。
LoadingCacheKey, Graph graphs Caffeine.newBuilder().maximumSize(10_000).refreshAfterWrite(1, TimeUnit.MINUTES).build(key - createExpensiveGraph(key));刷新和驱逐并不相同。可以通过LoadingCache.refresh(K)方法异步为key对应的缓存元素刷新一个新的值。与驱逐不同的是在刷新的时候如果查询缓存元素其旧值将仍被返回直到该元素的刷新完毕后结束后才会返回刷新后的新值。 与 expireAfterWrite相反refreshAfterWrite 将会使在写操作之后的一段时间后允许key对应的缓存元素进行刷新但是只有在这个key被真正查询到的时候才会正式进行刷新操作。所以打个比方你可以在同一个缓存中同时用到 refreshAfterWrite和expireAfterWrite 这样缓存元素的在被允许刷新的时候不会直接刷新使得过期时间被盲目重置。当一个元素在其被允许刷新但是没有被主动查询的时候这个元素也会被视为过期。 一个CacheLoader可以通过覆盖重写 CacheLoader.reload(K, V) 方法使得在刷新中可以将旧值也参与到更新的过程中去这也使得刷新操作显得更加智能。
计算
在复杂的工作流中当外部资源对key的操作变更顺序有要求的时候Caffeine 提供了实现的扩展点。 https://github.com/ben-manes/caffeine/wiki/Compute-zh-CN
Interner
InternerString interner Interner.newStrongInterner();
String s1 interner.intern(new String(value));
String s2 interner.intern(new String(value));
assert s1 s2一个 Interner 将会返回给定元素的标准规范形式。当调用 intern(e) 方法时如果该 interner 已经包含一个由 Object.equals 方法确认相等的对象的时候将会返回其中已经包含的对象。否则将会新添加该对象返回。这种重复数据删除通常用于共享规范实例来减少内存使用。 主要用于删除重复数据。
LoadingCacheKey, Graph graphs Caffeine.newBuilder().weakKeys().build(key - createExpensiveGraph(key));
InternerKey interner Interner.newWeakInterner();Key canonical interner.intern(key);
Graph graph graphs.get(canonical);一个弱引用的 interner 允许其中的内部对象在没有别的强引用的前提下在被 gc 回收。与 caffeine 的 Caffeine.weakKeys() 不同的是 这里通过 () 来进行比较而不是 equals()。这样可以确保应用程序所引用的 interner 中的值正是缓存中的实际实例。否则在缓存当中的所 持有的弱引用 key 很有可能是与应用程序所持有的实例不同的实例这会导致这个 key 会在 gc 的时候被提早从缓存当中被淘汰。
规范
springboot中有用到
CaffeineSpec spec CaffeineSpec.parse(maximumWeight1000, expireAfterWrite10m, recordStats);
LoadingCacheKey, Graph graphs Caffeine.from(spec).weigher((Key key, Graph graph) - graph.vertices().size()).build(key - createExpensiveGraph(key));CaffeineSpec为Caffeine提供了一个简单的字符格式配置。这里的字符串语法是一系列由逗号隔开的键值对组成其中每个键值对对应一个配置方法。但是这里的字符配置不支持需要对象来作为参数的配置方法比如 removalListener这样的配置必须要在代码中进行配置。 以下是各个配置键值对字符串所对应的配置方法。将maximumSize和maximumWeight或者将weakValues和weakValues 在一起使用是不被允许的。
initialCapacity[integer]: 相当于配置 Caffeine.initialCapacitymaximumSize[long]: 相当于配置 Caffeine.maximumSizemaximumWeight[long]: 相当于配置 Caffeine.maximumWeightexpireAfterAccess[持续时间]: 相当于配置 Caffeine.expireAfterAccessexpireAfterWrite[持续时间]: 相当于配置 Caffeine.expireAfterWriterefreshAfterWrite[持续时间]: 相当于配置 Caffeine.refreshAfterWriteweakKeys: 相当于配置 Caffeine.weakKeysweakValues: 相当于配置 Caffeine.weakValuessoftValues: 相当于配置 Caffeine.softValuesrecordStats: 相当于配置 Caffeine.recordStats
持续时间可以通过在一个integer类型之后跟上一个d“h”“m”或者s来分别表示天小时分钟或者秒。另外ISO-8601标准的字符串也被支持来配置持续时间并通过Duration.parse来进行解析。出于表示缓存持续时间的目的这里不支持配置负的持续时间并将会抛出异常。两种持续时间表示格式的示例如下所示。
普通ISO-8601描述50sPT50S50秒11mPT11M11分钟6hPT6H6小时3dP3D3天P3DT3H4M3天3小时4分钟-PT7H3M-7小时-3分钟不支持
