一、范例

LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES).removalListener(MY_LISTENER).build(new CacheLoader<Key, Graph>() {public Graph load(Key key) throws AnyException {return createExpensiveGraph(key);}});

二、应用场景

缓存在很多场景里面非常有用。例如当你需要多次访问一个计算或者查询加载耗时成本高时，你就可以考虑使用缓存。缓存在很多场景下都是相当有用的。例如，计算或检索一个值的代价很高，并且对同样的输入需要不止一次获取值的时候，就应当考虑使用缓存。

Guava Cache与ConcurrentMap很相似，但也不完全一样。最基本的区别是ConcurrentMap会一直保存所有添加的元素，直到显式地移除。相对地，Guava Cache为了限制内存占用，通常都设定为自动回收元素。在某些场景下，尽管LoadingCache 不回收元素，它也是很有用的，因为它会自动加载缓存。

通常来说，Guava Cache适用于：

• 消耗一些内存空间来提升速度。
• 某些键会被查询一次以上。
• 缓存中存放的数据总量不会超出内存容量。（Guava Cache是单个应用运行时的本地缓存。它不把数据存放到文件或外部服务器。如果这不符合你的需求，请尝试Memcached这类工具）。

三、加载

在使用缓存前，首先问自己一个问题：有没有合理的默认方法来加载或计算与键关联的值？如果有的话，你应当使用CacheLoader。如果没有，或者你想要覆盖默认的加载运算，同时保留"获取缓存-如果没有-则计算"[get-if-absent-compute]的原子语义，你应该在调用get时传入一个Callable实例。缓存元素也可以通过Cache.put方法直接插入，但自动加载是首选的，因为它可以更容易地推断所有缓存内容的一致性。以下有三种加载key-value到Cache中的方式：

• CacheLoader
• Callable
• put

1、CacheLoader

LoadingCache是附带CacheLoader构建而成的缓存实现。创建自己的CacheLoader通常只需要简单地实现V load(K key) throws Exception方法。例如，你可以用下面的代码构建LoadingCache：

LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder().maximumSize(1000).build(new CacheLoader<Key, Graph>() {public Graph load(Key key) throws AnyException {return createExpensiveGraph(key);}});...
try {return graphs.get(key);
} catch (ExecutionException e) {throw new OtherException(e.getCause());
}

从LoadingCache查询的正规方式是使用get(K)方法。这个方法要么返回已经缓存的值，要么使用CacheLoader向缓存原子地加载新值。由于CacheLoader可能抛出异常，LoadingCache.get(K)也声明为抛出ExecutionException异常。如果你定义的CacheLoader没有声明任何检查型异常，则可以通过getUnchecked(K)查找缓存；但必须注意，一旦CacheLoader声明了检查型异常，就不可以调用getUnchecked(K)。

getAll(Iterable<? extends K>)方法用来执行批量查询。默认情况下，对每个不在缓存中的键，getAll方法会单独调用CacheLoader.load来加载缓存项。如果批量的加载比多个单独加载更高效，你可以重载CacheLoader.loadAll来利用这一点。getAll(Iterable)的性能也会相应提升。

2、Callable

所有类型的Guava Cache，不管有没有自动加载功能，都支持get(K, Callable)方法。这个方法返回缓存中相应的值，或者用给定的Callable运算并把结果加入到缓存中。在整个加载方法完成前，缓存项相关的可观察状态都不会更改。这个方法简便地实现了模式"如果有缓存则返回；否则运算、缓存、然后返回"。

Cache<Key, Graph> cache = CacheBuilder.newBuilder().maximumSize(1000).build(); // look Ma, no CacheLoader
...
try {// If the key wasn't in the "easy to compute" group, we need to// do things the hard way.cache.get(key, new Callable<Key, Graph>() {@Overridepublic Value call() throws AnyException {return doThingsTheHardWay(key);}});
} catch (ExecutionException e) {throw new OtherException(e.getCause());
}

3、显式插入

使用cache.put(key, value)方法可以直接向缓存中插入值，这会直接覆盖掉给定键之前映射的值。使用Cache.asMap()视图提供的任何方法也能修改缓存。但请注意，asMap视图的任何方法都不能保证缓存项被原子地加载到缓存中。进一步说，asMap视图的原子运算在Guava Cache的原子加载范畴之外，所以相比于Cache.asMap().putIfAbsent(K, V)，Cache.get(K, Callable) 应该总是优先使用。

四、过期策略

不幸的是，我们总是没有足够的内存，去缓存所有想要的key-value。你必须决定什么时候不再持有某些key-value。Guava提供了三种基本的缓存过期策略：基于容量、基于时间和基于引用。

1、基于容量的过期策略

如果你的缓存不能超过一定容量，可以使用CacheBuilder.maximumSize(long)来设置。缓存会尝试回收最近没有被用或者没有被经常用的key-value。警告：可能会在缓存接近容量最大时，就执行回收操作。

另外，如果你缓存的value有不同权重（比如，占用内存的大小），可是使用CacheBuilder.weigher(Weigher)指定一个权重方法，并且通过CacheBuilder.maximumWeight(long)指定一个最大权重。警告：同样在接近最大权重的时候，可能就执行回收操作；而且权重方法是在创建或者覆盖时计算的，需要考虑该方法的复杂度。

LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder().maximumWeight(100000).weigher(new Weigher<Key, Graph>() {public int weigh(Key k, Graph g) {return g.vertices().size();}}).build(new CacheLoader<Key, Graph>() {public Graph load(Key key) { // no checked exceptionreturn createExpensiveGraph(key);}});

2、基于时间的过期策略

CacheBuilder提供两种时间过期策略：

• 基于访问时间过期（expireAfterAccess(long, TimeUnit)）当key-value在最近访问（读或者写）后一段时间就过期，比如设定10分钟过期，如果缓存被访问到，则以最后一次访问时间重新计时；只有连续10分钟没有被访问的时候才会过期，否则将一直存在缓存中不会被过期。

public Cache<String, User> createUserCache() {return CacheBuilder.newBuilder().expireAfterAccess(30L, TimeUnit.MINUTES).build();
}

• 基于创建时间过期（expireAfterWrite(long, TimeUnit)）当key-value在写入或者重新加载后一段时间就过期，比如设定10分钟过期，则记录加入缓存之后，不管有没有访问，10分钟时间到就过期。

public Cache<String, User> createUserCache() {return CacheBuilder.newBuilder().expireAfterWrite(30L, TimeUnit.MINUTES).build();
}

提示：对基于时间的过期策略进行测试，并不需要真正等时间过去很久，只需要使用CacheBuilder.ticker(Ticker) 方法就可以模拟测试了。

3、基于引用的过期策略

Guava支持使用弱引用设置key和value，使用软引用设置value。

• CacheBuilder.weakKeys() 用弱引用存储key，当key没有强和软引用的时候，key就可以被GC。
• CacheBuilder.weakValues() 用弱引用存储value，当value没有强和软引用的时候，value就可以被GC。
• CacheBuilder.softValues()用软引用存储value，当value没有强引用的时候，value在内存溢出之前，可以被GC。

Guava官方推荐使用更具有预测性基于容量的过期策略，而非是基于引用的过期策略。

五、显示清除

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

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

六、移除监听器

通过CacheBuilder.removalListener(RemovalListener)，你可以声明一个监听器，以便缓存项被移除时做一些额外操作。缓存项被移除时，RemovalListener会获取移除通知RemovalNotification，其中包含移除原因RemovalCause、键和值。
请注意：监听器里面任何异常都会被打印以及吞掉。

CacheLoader<Key, DatabaseConnection> loader = new CacheLoader<Key, DatabaseConnection> () {public DatabaseConnection load(Key key) throws Exception {return openConnection(key);}
};RemovalListener<Key, DatabaseConnection> removalListener = new RemovalListener<Key, DatabaseConnection>() {public void onRemoval(RemovalNotification<Key, DatabaseConnection> removal) {DatabaseConnection conn = removal.getValue();conn.close(); // tear down properly}
};return CacheBuilder.newBuilder().expireAfterWrite(2, TimeUnit.MINUTES).removalListener(removalListener).build(loader);

警告：默认情况下，监听器方法是在移除缓存时同步调用的。因为缓存的维护和请求响应通常是同时进行的，代价高昂的监听器方法在同步模式下会拖慢正常的缓存请求。在这种情况下，你可以使用RemovalListeners.asynchronous(RemovalListener, Executor)把监听器装饰为异步操作。

六、清理什么时候发生

用CacheBuilder构建的缓存不会"自动"执行清理和回收工作，也不会在某个缓存项过期后马上清理，也没有诸如此类的清理机制。相反，它会在写操作时顺带做少量的维护工作，或者偶尔在读操作时做——如果写操作实在太少的话。

这样做的原因在于：如果要自动地持续清理缓存，就必须有一个线程，这个线程会和用户操作竞争共享锁。此外，某些环境下线程创建可能受限制，这样CacheBuilder就不可用了。

相反，我们把选择权交到你手里。如果你的缓存是高吞吐的，那就无需担心缓存的维护和清理等工作。如果你的 缓存只会偶尔有写操作，而你又不想清理工作阻碍了读操作，那么可以创建自己的维护线程，以固定的时间间隔调用Cache.cleanUp()。ScheduledExecutorService可以帮助你很好地实现这样的定时调度。

七、刷新

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

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

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

//有些键不需要刷新，并且我们希望刷新是异步完成的
LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder().maximumSize(1000).refreshAfterWrite(1, TimeUnit.MINUTES).build(new CacheLoader<Key, Graph>() {public Graph load(Key key) { // no checked exceptionreturn getGraphFromDatabase(key);}public ListenableFuture<Key, Graph> reload(final Key key, Graph prevGraph) {if (neverNeedsRefresh(key)) {return Futures.immediateFuture(prevGraph);}else{// asynchronous!ListenableFutureTask<Key, Graph> task=ListenableFutureTask.create(new Callable<Key, Graph>() {public Graph call() {return getGraphFromDatabase(key);}});executor.execute(task);return task;}}});

CacheBuilder.refreshAfterWrite(long, TimeUnit)可以为缓存增加自动定时刷新功能。和expireAfterWrite相反，refreshAfterWrite通过定时刷新可以让缓存项保持可用，但请注意：缓存项只有在被检索时才会真正刷新（如果CacheLoader.refresh实现为异步，那么检索不会被刷新拖慢）。因此，如果你在缓存上同时声明expireAfterWrite和refreshAfterWrite，缓存并不会因为刷新盲目地定时重置，如果缓存项没有被检索，那刷新就不会真的发生，缓存项在过期时间后也变得可以回收。

八、支持更新锁定能力

这个是与上面数据源集成一起的辅助增强能力。在高并发场景下，如果某个key值没有命中缓存，大量的请求同步打到下游模块处理的时候，很容易造成缓存击穿问题。

为了防止缓存击穿问题，可以通过加锁的方式来规避。当缓存不可用时，仅持锁的线程负责从数据库中查询数据并写入缓存中，其余请求重试时先尝试从缓存中获取数据，避免所有的并发请求全部同时打到数据库上。

作为穿透型缓存的保护策略之一，Guava Cache自带了并发锁定机制，同一时刻仅允许一个请求去回源获取数据并回填到缓存中，而其余请求则阻塞等待，不会造成数据源的压力过大。