Guava Cache内存缓存使用实践-定时异步刷新及简单抽象封装

缓存在应用中是必不可少的，经常用的如redis、memcache以及内存缓存等。Guava是Google出的一个工具包，它里面的cache即是对本地内存缓存的一种实现，支持多种缓存过期策略。
Guava cache的缓存加载方式有两种：

• CacheLoader
• Callable callback

具体两种方式的介绍看官方文档：http://ifeve.com/google-guava-cachesexplained/

接下来看看常见的一些使用方法。
后面的示例实践都是以CacheLoader方式加载缓存值。

1.简单使用：定时过期

LoadingCache caches = CacheBuilder.newBuilder()
                .maximumSize(100)
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .build(new CacheLoader() {
                    @Override
                    public Object load(String key) throws Exception {
                        return generateValueByKey(key);
                    }
                });
try {
    System.out.println(caches.get("key-zorro"));
} catch (ExecutionException e) {
    e.printStackTrace();
}

如代码所示新建了名为caches的一个缓存对象，maximumSize定义了缓存的容量大小，当缓存数量即将到达容量上线时，则会进行缓存回收，回收最近没有使用或总体上很少使用的缓存项。需要注意的是在接近这个容量上限时就会发生，所以在定义这个值的时候需要视情况适量地增大一点。
另外通过expireAfterWrite这个方法定义了缓存的过期时间，写入十分钟之后过期。
在build方法里，传入了一个CacheLoader对象，重写了其中的load方法。当获取的缓存值不存在或已过期时，则会调用此load方法，进行缓存值的计算。
这就是最简单也是我们平常最常用的一种使用方法。定义了缓存大小、过期时间及缓存值生成方法。

如果用其他的缓存方式，如redis，我们知道上面这种“如果有缓存则返回；否则运算、缓存、然后返回”的缓存模式是有很大弊端的。当高并发条件下同时进行get操作，而此时缓存值已过期时，会导致大量线程都调用生成缓存值的方法，比如从数据库读取。这时候就容易造成大量请求同时查询数据库中该条记录，也就是“缓存击穿”。（之前说成“穿透”和“雪崩”，属于概念理解错误，感谢评论区指正）
而Guava cache则对此种情况有一定控制。当大量线程用相同的key获取缓存值时，只会有一个线程进入load方法，而其他线程则等待，直到缓存值被生成。这样也就避免了缓存击穿的危险。

2.进阶使用：定时刷新

如上的使用方法，虽然不会有缓存击穿的情况，但是每当某个缓存值过期时，老是会导致大量的请求线程被阻塞。而Guava则提供了另一种缓存策略，缓存值定时刷新：更新线程调用load方法更新该缓存，其他请求线程返回该缓存的旧值。这样对于某个key的缓存来说，只会有一个线程被阻塞，用来生成缓存值，而其他的线程都返回旧的缓存值，不会被阻塞。
这里就需要用到Guava cache的refreshAfterWrite方法。如下所示：

LoadingCache caches = CacheBuilder.newBuilder()
                .maximumSize(100)
                .refreshAfterWrite(10, TimeUnit.MINUTES)
                .build(new CacheLoader() {
                    @Override
                    public Object load(String key) throws Exception {
                        return generateValueByKey(key);
                    }
                });
try {
    System.out.println(caches.get("key-zorro"));
} catch (ExecutionException e) {
    e.printStackTrace();
}

如代码所示，每隔十分钟缓存值则会被刷新。

此外需要注意一个点，这里的定时并不是真正意义上的定时。Guava cache的刷新需要依靠用户请求线程，让该线程去进行load方法的调用，所以如果一直没有用户尝试获取该缓存值，则该缓存也并不会刷新。

3.进阶使用：异步刷新

如2中的使用方法，解决了同一个key的缓存过期时会让多个线程阻塞的问题，只会让用来执行刷新缓存操作的一个用户线程会被阻塞。由此可以想到另一个问题，当缓存的key很多时，高并发条件下大量线程同时获取不同key对应的缓存，此时依然会造成大量线程阻塞，并且给数据库带来很大压力。这个问题的解决办法就是将刷新缓存值的任务交给后台线程，所有的用户请求线程均返回旧的缓存值，这样就不会有用户线程被阻塞了。
详细做法如下：

ListeningExecutorService backgroundRefreshPools = 
				MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(20));
        LoadingCache caches = CacheBuilder.newBuilder()
                .maximumSize(100)
                .refreshAfterWrite(10, TimeUnit.MINUTES)
                .build(new CacheLoader() {
                    @Override
                    public Object load(String key) throws Exception {
                        return generateValueByKey(key);
                    }
                    
                    @Override
                    public ListenableFuture