Guava学习-缓存

Guava的缓存是本地缓存，所以我觉得在使用场景上适合那种并非是高一致性的场景中，而且他的实现和ConcurrentHashMap很类似。但是毕竟是缓存嘛，肯定有自动清除的功能。外加一些什么清除策略等等。

我们看guava的cache包下面也就是才十几个类，所以可以说知识一个基础工具，如果要使用到生产环境中去的话，那么还需要我们好好的进一步封装。

最主要的一个类就是LoadingCache，主要的创建方式也是很常见的构造器方式。

    @Test
    public void defaultCache(){
 
        LoadingCache<String, Integer> cache=CacheBuilder.newBuilder()
                .maximumSize(100)
                .expireAfterAccess(10, TimeUnit.SECONDS)
                //默认情况下  监听器是和移除操作是同步的  但是可以使用RemovalListeners.asynchronous 设置为异步
                .removalListener(RemovalListeners.asynchronous(new RemovalListenerImpl() {
                }, Executors.newCachedThreadPool()))
                .build(
                    new CacheLoader<String, Integer>(){
 
                        @Override
                        public Integer load(String key) throws Exception {
                            return loadValue();
                        }
                    }
                );

主要的几个参数最大值  过期时间，移除缓存的操作，加载缓存的操作(CacheLoader).

CacheLoader 

缓存的加载器，我们可以通过实现load()方法，通过key来加载value，如果值一旦加载完了之后，如果值没有失效并且没有被取代的话，那么下次根据这个KEY来获取值的话，那么就直接返回缓存中的值了。其他还有很多方法，比如reload()重载方法时调用，静态方法asyncReloading(...)对自定义的CacheLoader进行装饰，返回一个异步处理加载缓存发CacheLoader

获取缓存

1.

至于获取缓存，那么直接使用cache.get(key)就ok啦，但是当我们使用这个方法的时候，返回会抛出一个受检查的异常，这是因为我们在加载value的时候，会有可能抛出异常(load方法)，这个要取决我们自己，如果我们方法没有排除异常的话，像这样：

                    new CacheLoader<String, Integer>(){
 
                        @Override
                        public Integer load(String key){
 
                            return loadValue();
                        }
                    }

那么就可以不使用cache.get(key)，而采用cache.getUnchecked(key),那么我们就不用处理异常

2.

还有第二种方式加载缓存，就是使用Callable，但是如果我们自己也实现了CacheLoader的话，那么就会把这个逻辑给覆盖掉。如果要使用这种方式的哈，那么应该这样：

        Cache<String, Integer> cache=CacheBuilder.newBuilder()
                .maximumSize(100)
                .expireAfterAccess(10, TimeUnit.SECONDS)
                //默认情况下  监听器是和移除操作的同步的  但是可以使用RemovalListeners.asynchronous 设置为异步
                .removalListener(RemovalListeners.asynchronous(new RemovalListenerImpl() {
                    }, Executors.newCachedThreadPool()))
                .build();

显式插入

对于有一些场景 我们可能会一开始就将缓存加载到进去，那么之后获取的时候，就不需要那么麻烦的进行每次没有命中的时候，重新的计算。这个时候我们可以使用显式的加载缓存，

        //这个map将反应到缓存的中的项中  但是不能保证其的原子性
        cache.asMap().putIfAbsent("1", 1);
        cache.put("2", 2); //一般都优先的使用这种方式

其中asMap()方式返回一个缓存中的视图，我们也可以在上面进行操作，但是个人建议是只能拿来进行缓存的获取，不要拿来进行显式的插入，毕竟不是原子性的！

缓存回收的策略

基于容量最大值来进行回收

也就是缓存到达了一定数量之后，或者数量逼近的时候，那么就开始进行缓存的回收

.maximumSize(100)

基于权重的方式。权重越接近，那么就越接近回收

　　　　　　　　　 .maximumWeight(100)
                .weigher(new Weigher<String, Integer>() {
 
                    public int weigh(String key, Integer value) {
 
                        if("100".equals(key))
                            return 100;
 
                        return 0;
                    }
                })

定时回收，...Access 表示的是读写都会刷新时间   ...Write表示的是写入之后开始计时

.expireAfterAccess(3, TimeUnit.MINUTES)
.expireAfterWrite(10, TimeUnit.MINUTES)

基于引用的回收（Reference-based Eviction）

通过使用弱引用的键、或弱引用的值、或软引用的值，Guava Cache可以把缓存设置为允许垃圾回收

CacheBuilder.weakKeys()：使用弱引用存储键。当键没有其它（强或软）引用时，缓存项可以被垃圾回收。因为垃圾回收仅依赖恒等式（==），使用弱引用键的缓存用==而不是equals比较键。

CacheBuilder.weakValues()：使用弱引用存储值。当值没有其它（强或软）引用时，缓存项可以被垃圾回收。因为垃圾回收仅依赖恒等式（==），使用弱引用值的缓存用==而不是equals比较值。

CacheBuilder.softValues()：使用软引用存储值。软引用只有在响应内存需要时，才按照全局最近最少使用的顺序回收。考虑到使用软引用的性能影响，我们通常建议使用更有性能预测性的缓存大小限定（见上文，基于容量回收）。使用软引用值的缓存同样用==而不是equals比较值

显式清除

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

个别清除：Cache.invalidate(key)
批量清除：Cache.invalidateAll(keys)
清除所有缓存项：Cache.invalidateAll()

刷新缓存

刷新和回收不太一样。正如LoadingCache.refresh(K)所声明，刷新表示为键加载新值，这个过程可以是异步的。在刷新操作进行时，缓存仍然可以向其他线程返回旧值，而不像回收操作，读缓存的线程必须等待新值加载完成。

如果刷新过程抛出异常，缓存将保留旧值，而异常会在记录到日志后被丢弃[swallowed]。

重载CacheLoader.reload(K, V)可以扩展刷新时的行为，这个方法允许开发者在计算新值时使用旧的值。

统计

CacheBuilder.recordStats()用来开启Guava Cache的统计功能。统计打开后，Cache.stats()方法会返回CacheStats对象以提供如下统计信息：

　　hitRate()：缓存命中率；
　　averageLoadPenalty()：加载新值的平均时间，单位为纳秒；
　　evictionCount()：缓存项被回收的总数，不包括显式清除。

中断：

缓存加载方法（如Cache.get）不会抛出InterruptedException。我们也可以让这些方法支持InterruptedException，但这种支持注定是不完备的，并且会增加所有使用者的成本，而只有少数使用者实际获益。详情请继续阅读。

Cache.get请求到未缓存的值时会遇到两种情况：当前线程加载值；或等待另一个正在加载值的线程。这两种情况下的中断是不一样的。等待另一个正在加载值的线程属于较简单的情况：使用可中断的等待就实现了中断支持；但当前线程加载值的情况就比较复杂了：因为加载值的CacheLoader是由用户提供的，如果它是可中断的，那我们也可以实现支持中断，否则我们也无能为力。

如果用户提供的CacheLoader是可中断的，为什么不让Cache.get也支持中断？从某种意义上说，其实是支持的：如果CacheLoader抛出InterruptedException，Cache.get将立刻返回（就和其他异常情况一样）；此外，在加载缓存值的线程中，Cache.get捕捉到InterruptedException后将恢复中断，而其他线程中InterruptedException则被包装成了ExecutionException。

原则上，我们可以拆除包装，把ExecutionException变为InterruptedException，但这会让所有的LoadingCache使用者都要处理中断异常，即使他们提供的CacheLoader不是可中断的。如果你考虑到所有非加载线程的等待仍可以被中断，这种做法也许是值得的。但许多缓存只在单线程中使用，它们的用户仍然必须捕捉不可能抛出的InterruptedException异常。即使是那些跨线程共享缓存的用户，也只是有时候能中断他们的get调用，取决于那个线程先发出请求。

对于这个决定，我们的指导原则是让缓存始终表现得好像是在当前线程加载值。这个原则让使用缓存或每次都计算值可以简单地相互切换。如果老代码（加载值的代码）是不可中断的，那么新代码（使用缓存加载值的代码）多半也应该是不可中断的。

如上所述，Guava Cache在某种意义上支持中断。另一个意义上说，Guava Cache不支持中断，这使得LoadingCache成了一个有漏洞的抽象：当加载过程被中断了，就当作其他异常一样处理，这在大多数情况下是可以的；但如果多个线程在等待加载同一个缓存项，即使加载线程被中断了，它也不应该让其他线程都失败（捕获到包装在ExecutionException里的InterruptedException），正确的行为是让剩余的某个线程重试加载。为此，我们记录了一个bug。然而，与其冒着风险修复这个bug，我们可能会花更多的精力去实现另一个建议AsyncLoadingCache，这个实现会返回一个有正确中断行为的Future对象。