Google Guava 缓存（下）

缓存回收

一个残酷的现实是，我们几乎一定没有足够的内存缓存所有数据。 你你必须决定： 什么时候某个缓存项就不值得保留了？ Guava Cache提供了三种基本的缓存回收方式： 基于容量回收、定时回收和基于引用回收。

基于容量的回收（size-based eviction）

如果要规定缓存项的数目不超过固定值，只需使用 CacheBuilder.maximumSize(long) 。 缓存将尝试回收最近没有使用或总体上很少使用的缓存项。 ——警告： 在缓存项的数目达到限定值之前，缓存就可能进行回收操作——通常来说，这种情况发生在缓存项的数目逼近限定值时。

另外，不同的缓存项有不同的“权重”（weights）——例如，如果你的缓存值，占据完全不同的内存空间，你可以使用 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 exception

| return createExpensiveGraph(key);

| }

| });

定时回收（Timed Eviction）

CacheBuilder提供两种定时回收的方法：

• expireAfterAccess(long, TimeUnit) ： 缓存项在给定时间内没有被读/写访问，则回收。 请注意这种缓存的回收顺序和基于大小回收一样。

• expireAfterWrite(long, TimeUnit) ： 缓存项在给定时间内没有被写访问（创建或覆盖），则回收。 如果认为缓存数据总是在固定时候后变得陈旧不可用，这种回收方式是可取的。

如下文所讨论，定时回收周期性地在写操作中执行，偶尔在读操作中执行。

测试定时回收

对定时回收进行测试时，不一定非得花费两秒钟去测试两秒的过期。 你可以使用 Ticker 接口和 CacheBuilder.ticker(Ticker) 方法在缓存中自定义一个时间源，而不是非得用系统时钟。

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

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

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

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

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

显式清除

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

• 个别清除： Cache.invalidate(key)

• 批量清除： Cache.invalidateAll(keys)

• 清除所有缓存项： Cache.invalidateAll()

移除监听器

通过 CacheBuilder.removalListener(RemovalListener) ，你可以声明一个监听器，以便缓存项被移除时做一些额外操作。 缓存项被移除时， RemovalListener 会获取移除通知[ RemovalNotification ]，其中包含移除原因[ RemovalCause ]、键和值。

请注意，RemovalListener抛出的任何异常都会在记录到日志后被丢弃[swallowed]。

|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 exception

| return 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，缓存并不会因为刷新盲目地定时重置，如果缓存项没有被检索，那刷新就不会真的发生，缓存项在过期时间后也变得可以回收。

其他特性

统计

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

• hitRate() ： 缓存命中率；

• averageLoadPenalty() ： 加载新值的平均时间，单位为纳秒；

• evictionCount() ： 缓存项被回收的总数，不包括显式清除。

此外，还有其他很多统计信息。 这些统计信息对于调整缓存设置是至关重要的，在性能要求高的应用中我们建议密切关注这些数据。

asMap视图

asMap视图提供了缓存的ConcurrentMap形式，但asMap视图与缓存的交互需要注意：

• cache.asMap()包含当前所有加载到缓存的项。 因此相应地，cache.asMap().keySet()包含当前所有已加载键;

• asMap().get(key)实质上等同于cache.getIfPresent(key)，而且不会引起缓存项的加载。 这和Map的语义约定一致。

• 所有读写操作都会重置相关缓存项的访问时间，包括Cache.asMap().get(Object)方法和Cache.asMap().put(K, V)方法，但不包括Cache.asMap().containsKey(Object)方法，也不包括在Cache.asMap()的集合视图上的操作。 比如，遍历Cache.asMap().entrySet()不会重置缓存项的读取时间。

中断

缓存加载方法（如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对象。

(全文完)