1. 项目概述为什么我们需要Guava Cache做后端开发的朋友对缓存这个概念一定不陌生。无论是为了扛住瞬时高并发还是为了减少对数据库这类慢速存储的频繁访问缓存都是我们工具箱里的必备利器。你可能用过ConcurrentHashMap自己手搓一个简单的缓存也用过Ehcache、Caffeine或者分布式缓存如Redis。但很多时候我们需要的只是一个轻量级、高性能、功能丰富的本地内存缓存它应该像瑞士军刀一样开箱即用功能齐全同时又足够可靠。Google的Guava库里的Cache组件就是这样一个存在。我第一次接触Guava Cache是在一个需要高频读取用户配置的项目里。当时用HashMap加锁代码写得很别扭性能也上不去上Redis又觉得杀鸡用牛刀增加了系统复杂度和网络开销。直到发现了Guava Cache它完美地解决了我的痛点提供了基于引用的内存管理、多种失效策略、异步刷新、统计信息等一系列生产级特性而接入成本几乎为零。它不是一个独立的缓存框架而是Guava这个“Java开发者的瑞士军刀”库中的一个组件这意味着如果你的项目已经引入了Guava大概率是的那么你就可以直接享受这份便利。简单来说Guava Cache适用于你希望将一些计算昂贵或网络IO昂贵的对象保留在内存中并自动管理其生命周期何时创建、何时失效、何时被清理的场景。它比手动管理ConcurrentHashMap更强大、更安全比引入一个重量级缓存中间件更轻便、更快速。接下来我们就深入这把“军刀”的细节看看它到底怎么用以及如何用好。2. Guava Cache核心设计与思路拆解2.1 与ConcurrentHashMap的本质区别很多人第一反应是我用ConcurrentHashMap不也能做缓存吗为什么要用Guava Cache这是一个非常好的问题也是理解Guava Cache价值的起点。ConcurrentHashMap是一个优秀的并发Map实现但它只是一个容器。当你把它当缓存用时所有缓存该有的逻辑都需要你自己实现这包括但不限于过期失效你需要自己维护一个时间戳然后起一个定时任务去扫描清理过期的条目。这既低效又容易出错。内存控制当缓存条目太多时如何防止内存溢出你需要实现LRU最近最少使用或类似算法来自动驱逐旧条目。自己实现一个高效、线程安全的LRU并不简单。弱引用/软引用支持为了更灵活地利用GC来帮助管理内存你可能需要用到弱键或软值ConcurrentHashMap本身不提供这种基于引用的驱逐。原子性的“获取-计算-存入”操作典型的缓存模式是“如果缓存有则返回如果没有则计算、存入、再返回”。在并发环境下你需要用synchronized或ConcurrentHashMap的computeIfAbsent来保证计算逻辑只执行一次。Guava Cache将此模式内建并提供了更丰富的回调。统计你想知道缓存命中率怎么样吗ConcurrentHashMap可不会告诉你。Guava Cache在内部也使用了ConcurrentHashMap的思想但它是在此之上构建的一个完整的缓存框架。它帮你封装了上述所有复杂逻辑你只需要通过一个流畅的构建器Builder来声明你的需求比如“最大容量1000条”、“写入10分钟后过期”、“统计缓存命中率”剩下的脏活累活它全包了。2.2 两种加载模式CacheLoader与Callable这是Guava Cache设计的核心之一它明确了缓存数据如何加载。1. CacheLoader模式声明式加载这种方式适用于所有缓存值都可以通过同一个策略同一个函数计算出来的场景。比如通过用户ID加载用户信息。你在构建缓存时就需要提供一个CacheLoader实现类重写其load(key)方法。LoadingCacheKey, Graph cache CacheBuilder.newBuilder() .maximumSize(1000) .build( new CacheLoaderKey, Graph() { public Graph load(Key key) throws AnyException { return createExpensiveGraph(key); // 当缓存缺失时自动调用此方法加载 } });使用时你直接调用cache.get(key)。如果缓存中有直接返回如果没有Cache会自动调用你定义的load方法去加载数据放入缓存然后返回。这个过程对于调用者是透明的而且是线程安全的——如果多个线程同时请求同一个缺失的key默认情况下只有一个线程会执行load其他线程阻塞等待结果避免重复计算。2. Callable模式编程式加载这种方式更加灵活允许你在每次get的时候动态指定如何加载这个缺失的值。适用于不同key可能需要不同加载逻辑或者加载逻辑需要依赖本次调用上下文的情况。CacheKey, Value cache CacheBuilder.newBuilder().build(); // 注意这里构建的是Cache不是LoadingCache try { // 第二个参数是一个Callable仅在key不存在时被执行 Value value cache.get(key, new CallableValue() { Override public Value call() throws AnyException { return doSomethingTheHardWay(key); } }); } catch (ExecutionException e) { throw new OtherException(e.getCause()); }选择哪种模式如果你的缓存所有条目都遵循统一的加载逻辑用CacheLoader更简洁也能直接构建出LoadingCache使用更方便的API如getAll。如果加载逻辑多变或者你不想在构建时绑定加载器就用Callable模式。2.3 缓存的层次化构建思维使用CacheBuilder时你会发现它的方法链设计得非常优雅。这种设计引导你从几个维度去思考你的缓存策略容量边界我的缓存最多能存多少(maximumSize,maximumWeight)时间边界数据多久会过期(expireAfterWrite,expireAfterAccess)引用边界当内存紧张时如何借助GC帮忙(weakKeys,weakValues,softValues)行为控制是否开启统计(recordStats) 是否在移除时通知我(removalListener)这种声明式的配置让你从“如何实现缓存逻辑”的细节中解放出来专注于“我想要缓存有什么样的行为”。这是Guava Cache在易用性上的一大胜利。3. 核心细节解析与实操要点3.1 详解过期驱逐策略不只是TTL过期驱逐是缓存的核心功能。Guava Cache提供了两种基于时间的驱逐策略理解它们的区别至关重要。expireAfterWrite写入后过期顾名思义一个条目在被创建或值被替换之后经过固定时间就会过期。这是最常用、也是最符合直觉的策略。例如缓存一个从数据库查出的商品价格你希望即使数据库价格变了缓存里最多也只显示旧价格5分钟。5分钟后下一次请求会触发重新加载。注意这里的“写入”包括通过put方法放入、通过CacheLoader.load加载、通过Callable计算放入以及通过refresh刷新后放入。expireAfterAccess访问后过期一个条目在最后一次被读取或写入之后经过固定时间就会过期。这个策略适用于“热度”维持的场景。比如你缓存了用户的会话信息只要用户还在活跃访问读缓存这个会话就保持有效用户一旦10分钟没动静没读也没写会话就过期被清理。警告混合使用这两种策略时实际过期时间取两者中较小的那个。例如同时设置expireAfterWrite10m和expireAfterAccess5m那么一个条目即使刚写入如果5分钟内没人访问也会被驱逐。底层原理Guava Cache并没有为每个缓存项启动一个定时器那样成本太高。它采用的是惰性删除与定期清理相结合的方式。大部分清理工作发生在读操作、写操作或偶尔的维护性操作期间。这意味着一个过期的条目可能不会在精确的时间点被立即移除而是在你下次操作缓存时或者缓存维护线程运行时才被清理。这在绝大多数场景下是可接受的并且是高性能缓存库的通用做法。3.2 容量驱逐策略与权重系统除了时间缓存大小也必须受控。Guava Cache提供了两种容量控制方式maximumSize(long size)这是最直接的方式指定缓存可以包含的条目数量的最大值。当缓存大小逼近这个值时就会根据近似LRU最近最少使用算法来驱逐旧的条目。CacheBuilder.newBuilder().maximumSize(10000L) // 最多缓存1万个条目maximumWeight(long weight)与weigher有时候条目数不能准确反映内存占用。一个缓存了整数的条目和一个缓存了10MB图片的条目虽然都算一个“条目”但代价天差地别。这时就需要权重系统。首先你需要提供一个Weigher函数告诉Guava如何计算每个条目的权重。然后通过maximumWeight指定最大总权重。LoadingCacheKey, Graph graphs CacheBuilder.newBuilder() .maximumWeight(1000000) // 总权重上限例如代表约1MB内存 .weigher(new WeigherKey, Graph() { public int weigh(Key k, Graph g) { return g.vertices().size(); // 假设用图的顶点数作为权重 } }) .build( new CacheLoaderKey, Graph() { public Graph load(Key key) { // no checked exception return createExpensiveGraph(key); } });重要限制maximumSize和maximumWeight不能同时使用。权重计算是在条目创建和更新时进行的并且是不可变的——一旦计算后续即使值对象内部状态改变权重也不会重新计算。3.3 基于引用的驱逐与GC协作这是Guava Cache的一个高级特性允许你利用Java的垃圾回收机制来设置更灵活的驱逐策略。weakKeys()将键存储为弱引用。这意味着当键对象在缓存之外没有任何强引用或软引用时它可以被垃圾回收器回收。回收后对应的整个缓存条目会被自动驱逐。这常用于键是临时对象的场景。weakValues()将值存储为弱引用。当值对象在其他地方没有强/软引用时可以被GC回收条目被驱逐。softValues()将值存储为软引用。这是比弱引用更强的引用。只有当JVM内存不足即将发生OutOfMemoryError之前GC才会回收软引用对象。这相当于为缓存提供了一个“内存不足时的安全网”常用于实现内存敏感的缓存。CacheBuilder.newBuilder() .softValues() // 值使用软引用在内存紧张时会被GC自动清理 .build();实操心得使用引用驱逐特别是softValues()要非常小心。因为它依赖于GC行为而GC行为是不确定、不可控的。你无法精确预测条目何时被驱逐。因此它更适合作为缓存容量控制maximumSize的一个补充而不是主要驱逐策略。另外启用weakKeys或weakValues后缓存的身份比较如key1key2将使用代替equals()这可能会带来意想不到的行为需要确保你的使用场景符合其语义。3.4 显式清除与失效除了自动驱逐我们经常需要手动让某些缓存项失效。单个清除cache.invalidate(key)批量清除cache.invalidateAll(keys)全部清除cache.invalidateAll()这些操作是即时生效的。invalidate方法会触发移除监听器如果配置了这是清理资源如关闭文件句柄、网络连接的好时机。一个常见误区认为cache.put(key, null)可以清除缓存。这是错误的Guava Cache不允许存储null值。如果你尝试存入null或者CacheLoader.load返回null都会抛出异常。因为null通常表示“不存在”缓存一个“不存在”的意义不明确且容易导致歧义。如果你需要表示“某个key对应的数据就是空”应该使用一个特殊的哨兵对象如Optional.empty()或一个静态的NULL_PLACEHOLDER。4. 实操过程与核心环节实现4.1 构建一个生产可用的缓存实例让我们结合上述所有知识点构建一个功能相对完整的缓存用于缓存用户信息。import com.google.common.cache.*; import java.util.concurrent.TimeUnit; import java.util.concurrent.ExecutionException; public class UserCacheService { // 定义缓存 private final LoadingCacheString, User userCache; public UserCacheService() { this.userCache CacheBuilder.newBuilder() // 容量控制最多缓存10000个用户 .maximumSize(10000L) // 时间控制写入后30分钟过期保证数据不会太旧 .expireAfterWrite(30, TimeUnit.MINUTES) // 时间控制访问后10分钟过期保证活跃用户数据常驻 .expireAfterAccess(10, TimeUnit.MINUTES) // 开启统计功能 .recordStats() // 设置移除监听器用于资源清理或日志记录 .removalListener(new RemovalListenerString, User() { Override public void onRemoval(RemovalNotificationString, User notification) { RemovalCause cause notification.getCause(); String userId notification.getKey(); User user notification.getValue(); System.out.printf(用户缓存被移除: Key%s, Cause%s%n, userId, cause); // 可以在这里关闭user占用的资源如果它有的话 } }) // 构建LoadingCache指定数据加载方式 .build(new CacheLoaderString, User() { Override public User load(String userId) throws Exception { // 当缓存未命中时调用此方法加载数据 System.out.println(缓存未命中从数据库加载用户: userId); return loadUserFromDatabase(userId); // 模拟耗时操作 } Override public ListenableFutureUser reload(String key, User oldValue) throws Exception { // 定义异步刷新逻辑见4.2节 return super.reload(key, oldValue); // 默认是同步的这里先调用默认 } }); } // 模拟从数据库加载用户 private User loadUserFromDatabase(String userId) { try { Thread.sleep(100); // 模拟100ms的数据库查询耗时 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return new User(userId, 用户_ userId); } // 对外提供获取用户的方法 public User getUser(String userId) { try { return userCache.get(userId); } catch (ExecutionException e) { // load方法抛出的异常会被包装在ExecutionException中 throw new RuntimeException(加载用户信息失败: userId, e.getCause()); } } // 获取缓存统计信息 public CacheStats getStats() { return userCache.stats(); } // 手动失效某个用户缓存 public void invalidateUser(String userId) { userCache.invalidate(userId); } // 用户实体类 static class User { String id; String name; // 省略构造方法和getter/setter User(String id, String name) { this.id id; this.name name; } } }代码解读与注意事项链式调用CacheBuilder的配置顺序无关紧要但阅读时建议按容量、时间、功能统计、监听的顺序更清晰。移除监听器RemovalListener的onRemoval方法会在条目被移除任何原因过期、手动失效、容量驱逐等时被调用。注意这个回调默认是同步执行的如果回调逻辑很重会阻塞缓存操作。如果监听逻辑耗时务必使用RemovalListeners.asynchronous(RemovalListener, Executor)将其包装为异步。异常处理LoadingCache.get(key)会抛出ExecutionException你需要从中取出CacheLoader.load方法抛出的原始异常进行处理。统计信息recordStats()开启后可以通过cache.stats()获取一个不可变的CacheStats快照里面包含命中次数、未命中次数、加载成功/失败次数、总加载时间、驱逐计数等。这是监控缓存健康度、调整配置参数的宝贵依据。4.2 刷新与重载保持数据新鲜expireAfterWrite策略有个问题当一个热门条目过期时下一次请求该条目的线程必须等待load方法执行完成可能很慢导致请求延迟。为了解决这个问题Guava Cache提供了**刷新Refresh**机制。刷新 vs 失效重加载失效重加载条目过期后被移除下次get时同步加载调用线程阻塞等待。刷新条目在达到刷新时间后不会立即被移除。下次get时会异步触发重加载reload并立即返回旧的可能已过时值。新值加载完成后会原子性地替换旧值。这类似于CDN的边缘缓存刷新用户总能快速拿到一个版本的数据哪怕是旧的而更新在后台悄悄进行。如何启用刷新在构建LoadingCache时除了expireAfterWrite还可以配置refreshAfterWrite。LoadingCacheKey, Graph graphs CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) // 10分钟后完全过期 .refreshAfterWrite(1, TimeUnit.MINUTES) // 写入1分钟后再次访问可触发刷新 .build( new CacheLoaderKey, Graph() { public Graph load(Key key) { // 同步加载 return getGraphFromDatabase(key); } public ListenableFutureGraph reload(Key key, Graph oldValue) { // 提供异步刷新实现 return ListenableFutureTask.create(() - getGraphFromDatabase(key)); } });关键点解析refreshAfterWrite必须和expireAfterWrite一起使用且刷新时间应小于过期时间。上例中数据写入1分钟后进入“可刷新”状态但10分钟后才会被强制过期驱逐。刷新是惰性的。条目达到刷新时间后并不会自动刷新。只有当有线程调用get请求该条目时如果发现它已进入可刷新状态才会触发刷新。触发刷新时默认会调用CacheLoader.reload方法。默认的reload实现是同步的直接调用load。为了不阻塞get的调用线程你必须重写reload方法返回一个ListenableFuture这样刷新操作才会在后台异步执行。通常我们会用一个线程池来执行这个耗时的重加载任务。在刷新完成前所有请求该key的线程得到的都是旧值。刷新过程中如果reload失败异常缓存条目会保持旧值不变。4.3 批量操作与视图LoadingCache提供了批量获取的getAll(Iterable keys)方法。它会尝试从缓存中获取所有给定的keys。对于缓存中不存在的key它会分别调用load方法来加载。默认实现是顺序加载每个缺失的key。你可以通过覆盖CacheLoader.loadAll方法来提供更高效的批量加载实现例如用一个SQL的IN查询加载所有缺失用户但这需要谨慎因为并非所有场景都适合批量加载。此外你可以通过cache.asMap()方法获得一个ConcurrentMap视图。但请务必小心这个视图反映了缓存的所有条目但通过它进行的操作如size(),isEmpty(),clear()会影响到缓存。更重要的是asMap().get(key)不会触发自动加载它只是简单地查找如果不存在就返回null。同时asMap().put(key, value)会绕过所有缓存策略如过期时间、权重计算直接插入这可能会破坏缓存的一致性。通常只在需要遍历所有缓存条目等特殊场景下才使用asMap()。5. 常见问题与排查技巧实录在实际使用Guava Cache的过程中我踩过不少坑也总结了一些排查问题的经验。5.1 内存泄漏与引用误用问题场景缓存似乎永远在增长即使设置了maximumSize和过期时间通过监控发现缓存条目数远超预期。排查思路检查键对象的hashCode和equals方法这是最隐蔽的坑。如果你的键对象比如一个自定义的DTO没有正确重写hashCode和equals方法那么每次put一个“逻辑相同”但“物理不同”的对象都会被当作不同的key。例如键是一个ListString两次传入内容相同的new ArrayList(...)由于List的equals比较内容但如果你错误地使用了身份比较就会出问题。确保作为键的对象是不可变的并正确实现了hashCode和equals。检查是否启用了weakKeys/weakValues如果启用了特别是weakKeys意味着缓存对键的引用很弱。如果你的键在其他地方没有强引用可能会被GC意外回收导致你无法通过原有的键对象再找到缓存条目虽然条目可能还在。这看起来像是“内存泄漏”东西放进去不见了其实是引用策略导致。权重计算错误如果使用了maximumWeight检查Weigher实现是否正确。权重计算错误可能导致缓存过早驱逐或永远达不到驱逐条件。监听器阻塞如果你的RemovalListener是同步的并且执行非常缓慢它可能会阻塞缓存的管理线程导致驱逐、清理等后台任务被延迟从表象上看就是缓存堆积。实操心得对于生产缓存务必开启recordStats()并定期打印CacheStats。重点关注evictionCount驱逐计数如果这个数一直为0而缓存条目数又在涨那很可能就是容量驱逐没生效需要检查maximumSize或maximumWeight的设置是否合理或者是否存在上述的键重复问题。5.2 缓存击穿与雪崩缓存击穿某个热点key过期瞬间有大量请求同时到达所有请求都发现缓存失效于是都去执行加载逻辑如查数据库造成数据库压力激增。Guava Cache的应对对于LoadingCacheget方法在加载缺失key时默认是加锁的。也就是说对于同一个key即使有100个线程同时调用get也只有一个线程会执行CacheLoader.load其他线程会阻塞等待该线程加载完成。这完美地防止了缓存击穿。但要注意如果加载时间过长会导致大量线程阻塞。缓存雪崩大量key在同一时间点过期导致所有请求都涌向后端。应对策略差异化过期时间在设置expireAfterWrite时不要对所有key使用固定的时长。可以加一个随机范围例如30分钟 Random.nextInt(10)分钟让过期时间分散开。使用刷新机制对于热点数据采用refreshAfterWrite。这样在数据变“旧”时访问会触发后台异步刷新用户无感也避免了同步加载的阻塞和雪崩。永不过期 主动更新对于一些极其关键且更新不频繁的配置数据可以考虑设置很长的过期时间然后通过后台定时任务或消息通知来主动invalidate并重新加载。5.3 性能监控与调优CacheStats是你的最佳朋友。以下是一些关键指标及其意义指标说明调优方向hitRate()缓存命中率。命中次数 / 请求次数。理想情况应较高如0.8。过低可能说明容量太小或数据局部性差。missRate()缓存未命中率。1 - hitRate。与命中率相对。loadSuccessCount()成功加载新值的次数。loadExceptionCount()加载新值抛出异常的次数。异常率过高需检查CacheLoader.load逻辑的稳定性。totalLoadTime()加载新值花费的总时间纳秒。可计算平均加载时间。加载时间过长是性能瓶颈。evictionCount()因容量或过期策略被自动驱逐的条目总数。如果持续很高说明缓存容量可能不足频繁换入换出。averageLoadPenalty()平均加载耗时纳秒。直接反映load方法的性能。调优步骤记录基线在应用压力平稳时记录一套CacheStats数据作为基线。压力测试模拟生产流量进行压测。分析指标如果hitRate很低且evictionCount很高考虑增大maximumSize。如果averageLoadPenalty很高需要优化load方法如优化SQL、增加二级缓存。如果loadExceptionCount不为0需要增强load方法的健壮性考虑降级策略。调整参数根据分析调整容量、过期时间、刷新时间等参数再次压测验证。5.4 线程池与异步刷新如前所述实现真正的异步刷新需要重写reload方法并使用线程池。这里给出一个更工程化的示例import com.google.common.util.concurrent.ListenableFuture; import com.google.common.util.concurrent.ListeningExecutorService; import com.google.common.util.concurrent.MoreExecutors; import java.util.concurrent.Executors; public class AsyncRefreshCache { private final ListeningExecutorService refreshExecutor MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(5)); private final LoadingCacheString, String cache; public AsyncRefreshCache() { this.cache CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) .refreshAfterWrite(1, TimeUnit.MINUTES) .build(new CacheLoaderString, String() { Override public String load(String key) { return fetchFromSource(key); // 同步加载 } Override public ListenableFutureString reload(String key, String oldValue) { // 关键将同步的load操作提交到线程池返回Future return refreshExecutor.submit(() - fetchFromSource(key)); } }); } private String fetchFromSource(String key) { // 模拟耗时的数据获取 try { Thread.sleep(1000); } catch (InterruptedException e) { /* ... */ } return data_for_ key; } }注意事项这个自定义的线程池refreshExecutor需要根据业务量合理设置大小并在服务关闭时妥善关闭 (shutdown())否则会造成线程泄漏。5.5 Guava Cache不是银弹最后必须清醒认识到Guava Cache的局限性它是本地缓存数据只在单个JVM进程中有效。在分布式环境下你需要处理缓存一致性问题如使用Redis并配合发布订阅或者干脆直接用分布式缓存。它基于JVM堆内存缓存容量受限于JVM堆大小。存储大对象如图片、文件流需谨慎可能引发Full GC。持久化Guava Cache不提供持久化到磁盘的功能。应用重启缓存就没了。如果需要持久化需要考虑其他方案或在应用启动时预热缓存。因此它的最佳定位是分布式缓存如Redis之前的一道高性能、防穿透的本地屏障或者用于缓存那些与机器实例绑定、无需全局一致的数据如本地计算的中间结果、短时间内有效的锁状态等。理解边界才能用好工具。
深入解析Guava Cache：本地缓存的原理、核心特性与生产实践
1. 项目概述为什么我们需要Guava Cache做后端开发的朋友对缓存这个概念一定不陌生。无论是为了扛住瞬时高并发还是为了减少对数据库这类慢速存储的频繁访问缓存都是我们工具箱里的必备利器。你可能用过ConcurrentHashMap自己手搓一个简单的缓存也用过Ehcache、Caffeine或者分布式缓存如Redis。但很多时候我们需要的只是一个轻量级、高性能、功能丰富的本地内存缓存它应该像瑞士军刀一样开箱即用功能齐全同时又足够可靠。Google的Guava库里的Cache组件就是这样一个存在。我第一次接触Guava Cache是在一个需要高频读取用户配置的项目里。当时用HashMap加锁代码写得很别扭性能也上不去上Redis又觉得杀鸡用牛刀增加了系统复杂度和网络开销。直到发现了Guava Cache它完美地解决了我的痛点提供了基于引用的内存管理、多种失效策略、异步刷新、统计信息等一系列生产级特性而接入成本几乎为零。它不是一个独立的缓存框架而是Guava这个“Java开发者的瑞士军刀”库中的一个组件这意味着如果你的项目已经引入了Guava大概率是的那么你就可以直接享受这份便利。简单来说Guava Cache适用于你希望将一些计算昂贵或网络IO昂贵的对象保留在内存中并自动管理其生命周期何时创建、何时失效、何时被清理的场景。它比手动管理ConcurrentHashMap更强大、更安全比引入一个重量级缓存中间件更轻便、更快速。接下来我们就深入这把“军刀”的细节看看它到底怎么用以及如何用好。2. Guava Cache核心设计与思路拆解2.1 与ConcurrentHashMap的本质区别很多人第一反应是我用ConcurrentHashMap不也能做缓存吗为什么要用Guava Cache这是一个非常好的问题也是理解Guava Cache价值的起点。ConcurrentHashMap是一个优秀的并发Map实现但它只是一个容器。当你把它当缓存用时所有缓存该有的逻辑都需要你自己实现这包括但不限于过期失效你需要自己维护一个时间戳然后起一个定时任务去扫描清理过期的条目。这既低效又容易出错。内存控制当缓存条目太多时如何防止内存溢出你需要实现LRU最近最少使用或类似算法来自动驱逐旧条目。自己实现一个高效、线程安全的LRU并不简单。弱引用/软引用支持为了更灵活地利用GC来帮助管理内存你可能需要用到弱键或软值ConcurrentHashMap本身不提供这种基于引用的驱逐。原子性的“获取-计算-存入”操作典型的缓存模式是“如果缓存有则返回如果没有则计算、存入、再返回”。在并发环境下你需要用synchronized或ConcurrentHashMap的computeIfAbsent来保证计算逻辑只执行一次。Guava Cache将此模式内建并提供了更丰富的回调。统计你想知道缓存命中率怎么样吗ConcurrentHashMap可不会告诉你。Guava Cache在内部也使用了ConcurrentHashMap的思想但它是在此之上构建的一个完整的缓存框架。它帮你封装了上述所有复杂逻辑你只需要通过一个流畅的构建器Builder来声明你的需求比如“最大容量1000条”、“写入10分钟后过期”、“统计缓存命中率”剩下的脏活累活它全包了。2.2 两种加载模式CacheLoader与Callable这是Guava Cache设计的核心之一它明确了缓存数据如何加载。1. CacheLoader模式声明式加载这种方式适用于所有缓存值都可以通过同一个策略同一个函数计算出来的场景。比如通过用户ID加载用户信息。你在构建缓存时就需要提供一个CacheLoader实现类重写其load(key)方法。LoadingCacheKey, Graph cache CacheBuilder.newBuilder() .maximumSize(1000) .build( new CacheLoaderKey, Graph() { public Graph load(Key key) throws AnyException { return createExpensiveGraph(key); // 当缓存缺失时自动调用此方法加载 } });使用时你直接调用cache.get(key)。如果缓存中有直接返回如果没有Cache会自动调用你定义的load方法去加载数据放入缓存然后返回。这个过程对于调用者是透明的而且是线程安全的——如果多个线程同时请求同一个缺失的key默认情况下只有一个线程会执行load其他线程阻塞等待结果避免重复计算。2. Callable模式编程式加载这种方式更加灵活允许你在每次get的时候动态指定如何加载这个缺失的值。适用于不同key可能需要不同加载逻辑或者加载逻辑需要依赖本次调用上下文的情况。CacheKey, Value cache CacheBuilder.newBuilder().build(); // 注意这里构建的是Cache不是LoadingCache try { // 第二个参数是一个Callable仅在key不存在时被执行 Value value cache.get(key, new CallableValue() { Override public Value call() throws AnyException { return doSomethingTheHardWay(key); } }); } catch (ExecutionException e) { throw new OtherException(e.getCause()); }选择哪种模式如果你的缓存所有条目都遵循统一的加载逻辑用CacheLoader更简洁也能直接构建出LoadingCache使用更方便的API如getAll。如果加载逻辑多变或者你不想在构建时绑定加载器就用Callable模式。2.3 缓存的层次化构建思维使用CacheBuilder时你会发现它的方法链设计得非常优雅。这种设计引导你从几个维度去思考你的缓存策略容量边界我的缓存最多能存多少(maximumSize,maximumWeight)时间边界数据多久会过期(expireAfterWrite,expireAfterAccess)引用边界当内存紧张时如何借助GC帮忙(weakKeys,weakValues,softValues)行为控制是否开启统计(recordStats) 是否在移除时通知我(removalListener)这种声明式的配置让你从“如何实现缓存逻辑”的细节中解放出来专注于“我想要缓存有什么样的行为”。这是Guava Cache在易用性上的一大胜利。3. 核心细节解析与实操要点3.1 详解过期驱逐策略不只是TTL过期驱逐是缓存的核心功能。Guava Cache提供了两种基于时间的驱逐策略理解它们的区别至关重要。expireAfterWrite写入后过期顾名思义一个条目在被创建或值被替换之后经过固定时间就会过期。这是最常用、也是最符合直觉的策略。例如缓存一个从数据库查出的商品价格你希望即使数据库价格变了缓存里最多也只显示旧价格5分钟。5分钟后下一次请求会触发重新加载。注意这里的“写入”包括通过put方法放入、通过CacheLoader.load加载、通过Callable计算放入以及通过refresh刷新后放入。expireAfterAccess访问后过期一个条目在最后一次被读取或写入之后经过固定时间就会过期。这个策略适用于“热度”维持的场景。比如你缓存了用户的会话信息只要用户还在活跃访问读缓存这个会话就保持有效用户一旦10分钟没动静没读也没写会话就过期被清理。警告混合使用这两种策略时实际过期时间取两者中较小的那个。例如同时设置expireAfterWrite10m和expireAfterAccess5m那么一个条目即使刚写入如果5分钟内没人访问也会被驱逐。底层原理Guava Cache并没有为每个缓存项启动一个定时器那样成本太高。它采用的是惰性删除与定期清理相结合的方式。大部分清理工作发生在读操作、写操作或偶尔的维护性操作期间。这意味着一个过期的条目可能不会在精确的时间点被立即移除而是在你下次操作缓存时或者缓存维护线程运行时才被清理。这在绝大多数场景下是可接受的并且是高性能缓存库的通用做法。3.2 容量驱逐策略与权重系统除了时间缓存大小也必须受控。Guava Cache提供了两种容量控制方式maximumSize(long size)这是最直接的方式指定缓存可以包含的条目数量的最大值。当缓存大小逼近这个值时就会根据近似LRU最近最少使用算法来驱逐旧的条目。CacheBuilder.newBuilder().maximumSize(10000L) // 最多缓存1万个条目maximumWeight(long weight)与weigher有时候条目数不能准确反映内存占用。一个缓存了整数的条目和一个缓存了10MB图片的条目虽然都算一个“条目”但代价天差地别。这时就需要权重系统。首先你需要提供一个Weigher函数告诉Guava如何计算每个条目的权重。然后通过maximumWeight指定最大总权重。LoadingCacheKey, Graph graphs CacheBuilder.newBuilder() .maximumWeight(1000000) // 总权重上限例如代表约1MB内存 .weigher(new WeigherKey, Graph() { public int weigh(Key k, Graph g) { return g.vertices().size(); // 假设用图的顶点数作为权重 } }) .build( new CacheLoaderKey, Graph() { public Graph load(Key key) { // no checked exception return createExpensiveGraph(key); } });重要限制maximumSize和maximumWeight不能同时使用。权重计算是在条目创建和更新时进行的并且是不可变的——一旦计算后续即使值对象内部状态改变权重也不会重新计算。3.3 基于引用的驱逐与GC协作这是Guava Cache的一个高级特性允许你利用Java的垃圾回收机制来设置更灵活的驱逐策略。weakKeys()将键存储为弱引用。这意味着当键对象在缓存之外没有任何强引用或软引用时它可以被垃圾回收器回收。回收后对应的整个缓存条目会被自动驱逐。这常用于键是临时对象的场景。weakValues()将值存储为弱引用。当值对象在其他地方没有强/软引用时可以被GC回收条目被驱逐。softValues()将值存储为软引用。这是比弱引用更强的引用。只有当JVM内存不足即将发生OutOfMemoryError之前GC才会回收软引用对象。这相当于为缓存提供了一个“内存不足时的安全网”常用于实现内存敏感的缓存。CacheBuilder.newBuilder() .softValues() // 值使用软引用在内存紧张时会被GC自动清理 .build();实操心得使用引用驱逐特别是softValues()要非常小心。因为它依赖于GC行为而GC行为是不确定、不可控的。你无法精确预测条目何时被驱逐。因此它更适合作为缓存容量控制maximumSize的一个补充而不是主要驱逐策略。另外启用weakKeys或weakValues后缓存的身份比较如key1key2将使用代替equals()这可能会带来意想不到的行为需要确保你的使用场景符合其语义。3.4 显式清除与失效除了自动驱逐我们经常需要手动让某些缓存项失效。单个清除cache.invalidate(key)批量清除cache.invalidateAll(keys)全部清除cache.invalidateAll()这些操作是即时生效的。invalidate方法会触发移除监听器如果配置了这是清理资源如关闭文件句柄、网络连接的好时机。一个常见误区认为cache.put(key, null)可以清除缓存。这是错误的Guava Cache不允许存储null值。如果你尝试存入null或者CacheLoader.load返回null都会抛出异常。因为null通常表示“不存在”缓存一个“不存在”的意义不明确且容易导致歧义。如果你需要表示“某个key对应的数据就是空”应该使用一个特殊的哨兵对象如Optional.empty()或一个静态的NULL_PLACEHOLDER。4. 实操过程与核心环节实现4.1 构建一个生产可用的缓存实例让我们结合上述所有知识点构建一个功能相对完整的缓存用于缓存用户信息。import com.google.common.cache.*; import java.util.concurrent.TimeUnit; import java.util.concurrent.ExecutionException; public class UserCacheService { // 定义缓存 private final LoadingCacheString, User userCache; public UserCacheService() { this.userCache CacheBuilder.newBuilder() // 容量控制最多缓存10000个用户 .maximumSize(10000L) // 时间控制写入后30分钟过期保证数据不会太旧 .expireAfterWrite(30, TimeUnit.MINUTES) // 时间控制访问后10分钟过期保证活跃用户数据常驻 .expireAfterAccess(10, TimeUnit.MINUTES) // 开启统计功能 .recordStats() // 设置移除监听器用于资源清理或日志记录 .removalListener(new RemovalListenerString, User() { Override public void onRemoval(RemovalNotificationString, User notification) { RemovalCause cause notification.getCause(); String userId notification.getKey(); User user notification.getValue(); System.out.printf(用户缓存被移除: Key%s, Cause%s%n, userId, cause); // 可以在这里关闭user占用的资源如果它有的话 } }) // 构建LoadingCache指定数据加载方式 .build(new CacheLoaderString, User() { Override public User load(String userId) throws Exception { // 当缓存未命中时调用此方法加载数据 System.out.println(缓存未命中从数据库加载用户: userId); return loadUserFromDatabase(userId); // 模拟耗时操作 } Override public ListenableFutureUser reload(String key, User oldValue) throws Exception { // 定义异步刷新逻辑见4.2节 return super.reload(key, oldValue); // 默认是同步的这里先调用默认 } }); } // 模拟从数据库加载用户 private User loadUserFromDatabase(String userId) { try { Thread.sleep(100); // 模拟100ms的数据库查询耗时 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return new User(userId, 用户_ userId); } // 对外提供获取用户的方法 public User getUser(String userId) { try { return userCache.get(userId); } catch (ExecutionException e) { // load方法抛出的异常会被包装在ExecutionException中 throw new RuntimeException(加载用户信息失败: userId, e.getCause()); } } // 获取缓存统计信息 public CacheStats getStats() { return userCache.stats(); } // 手动失效某个用户缓存 public void invalidateUser(String userId) { userCache.invalidate(userId); } // 用户实体类 static class User { String id; String name; // 省略构造方法和getter/setter User(String id, String name) { this.id id; this.name name; } } }代码解读与注意事项链式调用CacheBuilder的配置顺序无关紧要但阅读时建议按容量、时间、功能统计、监听的顺序更清晰。移除监听器RemovalListener的onRemoval方法会在条目被移除任何原因过期、手动失效、容量驱逐等时被调用。注意这个回调默认是同步执行的如果回调逻辑很重会阻塞缓存操作。如果监听逻辑耗时务必使用RemovalListeners.asynchronous(RemovalListener, Executor)将其包装为异步。异常处理LoadingCache.get(key)会抛出ExecutionException你需要从中取出CacheLoader.load方法抛出的原始异常进行处理。统计信息recordStats()开启后可以通过cache.stats()获取一个不可变的CacheStats快照里面包含命中次数、未命中次数、加载成功/失败次数、总加载时间、驱逐计数等。这是监控缓存健康度、调整配置参数的宝贵依据。4.2 刷新与重载保持数据新鲜expireAfterWrite策略有个问题当一个热门条目过期时下一次请求该条目的线程必须等待load方法执行完成可能很慢导致请求延迟。为了解决这个问题Guava Cache提供了**刷新Refresh**机制。刷新 vs 失效重加载失效重加载条目过期后被移除下次get时同步加载调用线程阻塞等待。刷新条目在达到刷新时间后不会立即被移除。下次get时会异步触发重加载reload并立即返回旧的可能已过时值。新值加载完成后会原子性地替换旧值。这类似于CDN的边缘缓存刷新用户总能快速拿到一个版本的数据哪怕是旧的而更新在后台悄悄进行。如何启用刷新在构建LoadingCache时除了expireAfterWrite还可以配置refreshAfterWrite。LoadingCacheKey, Graph graphs CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) // 10分钟后完全过期 .refreshAfterWrite(1, TimeUnit.MINUTES) // 写入1分钟后再次访问可触发刷新 .build( new CacheLoaderKey, Graph() { public Graph load(Key key) { // 同步加载 return getGraphFromDatabase(key); } public ListenableFutureGraph reload(Key key, Graph oldValue) { // 提供异步刷新实现 return ListenableFutureTask.create(() - getGraphFromDatabase(key)); } });关键点解析refreshAfterWrite必须和expireAfterWrite一起使用且刷新时间应小于过期时间。上例中数据写入1分钟后进入“可刷新”状态但10分钟后才会被强制过期驱逐。刷新是惰性的。条目达到刷新时间后并不会自动刷新。只有当有线程调用get请求该条目时如果发现它已进入可刷新状态才会触发刷新。触发刷新时默认会调用CacheLoader.reload方法。默认的reload实现是同步的直接调用load。为了不阻塞get的调用线程你必须重写reload方法返回一个ListenableFuture这样刷新操作才会在后台异步执行。通常我们会用一个线程池来执行这个耗时的重加载任务。在刷新完成前所有请求该key的线程得到的都是旧值。刷新过程中如果reload失败异常缓存条目会保持旧值不变。4.3 批量操作与视图LoadingCache提供了批量获取的getAll(Iterable keys)方法。它会尝试从缓存中获取所有给定的keys。对于缓存中不存在的key它会分别调用load方法来加载。默认实现是顺序加载每个缺失的key。你可以通过覆盖CacheLoader.loadAll方法来提供更高效的批量加载实现例如用一个SQL的IN查询加载所有缺失用户但这需要谨慎因为并非所有场景都适合批量加载。此外你可以通过cache.asMap()方法获得一个ConcurrentMap视图。但请务必小心这个视图反映了缓存的所有条目但通过它进行的操作如size(),isEmpty(),clear()会影响到缓存。更重要的是asMap().get(key)不会触发自动加载它只是简单地查找如果不存在就返回null。同时asMap().put(key, value)会绕过所有缓存策略如过期时间、权重计算直接插入这可能会破坏缓存的一致性。通常只在需要遍历所有缓存条目等特殊场景下才使用asMap()。5. 常见问题与排查技巧实录在实际使用Guava Cache的过程中我踩过不少坑也总结了一些排查问题的经验。5.1 内存泄漏与引用误用问题场景缓存似乎永远在增长即使设置了maximumSize和过期时间通过监控发现缓存条目数远超预期。排查思路检查键对象的hashCode和equals方法这是最隐蔽的坑。如果你的键对象比如一个自定义的DTO没有正确重写hashCode和equals方法那么每次put一个“逻辑相同”但“物理不同”的对象都会被当作不同的key。例如键是一个ListString两次传入内容相同的new ArrayList(...)由于List的equals比较内容但如果你错误地使用了身份比较就会出问题。确保作为键的对象是不可变的并正确实现了hashCode和equals。检查是否启用了weakKeys/weakValues如果启用了特别是weakKeys意味着缓存对键的引用很弱。如果你的键在其他地方没有强引用可能会被GC意外回收导致你无法通过原有的键对象再找到缓存条目虽然条目可能还在。这看起来像是“内存泄漏”东西放进去不见了其实是引用策略导致。权重计算错误如果使用了maximumWeight检查Weigher实现是否正确。权重计算错误可能导致缓存过早驱逐或永远达不到驱逐条件。监听器阻塞如果你的RemovalListener是同步的并且执行非常缓慢它可能会阻塞缓存的管理线程导致驱逐、清理等后台任务被延迟从表象上看就是缓存堆积。实操心得对于生产缓存务必开启recordStats()并定期打印CacheStats。重点关注evictionCount驱逐计数如果这个数一直为0而缓存条目数又在涨那很可能就是容量驱逐没生效需要检查maximumSize或maximumWeight的设置是否合理或者是否存在上述的键重复问题。5.2 缓存击穿与雪崩缓存击穿某个热点key过期瞬间有大量请求同时到达所有请求都发现缓存失效于是都去执行加载逻辑如查数据库造成数据库压力激增。Guava Cache的应对对于LoadingCacheget方法在加载缺失key时默认是加锁的。也就是说对于同一个key即使有100个线程同时调用get也只有一个线程会执行CacheLoader.load其他线程会阻塞等待该线程加载完成。这完美地防止了缓存击穿。但要注意如果加载时间过长会导致大量线程阻塞。缓存雪崩大量key在同一时间点过期导致所有请求都涌向后端。应对策略差异化过期时间在设置expireAfterWrite时不要对所有key使用固定的时长。可以加一个随机范围例如30分钟 Random.nextInt(10)分钟让过期时间分散开。使用刷新机制对于热点数据采用refreshAfterWrite。这样在数据变“旧”时访问会触发后台异步刷新用户无感也避免了同步加载的阻塞和雪崩。永不过期 主动更新对于一些极其关键且更新不频繁的配置数据可以考虑设置很长的过期时间然后通过后台定时任务或消息通知来主动invalidate并重新加载。5.3 性能监控与调优CacheStats是你的最佳朋友。以下是一些关键指标及其意义指标说明调优方向hitRate()缓存命中率。命中次数 / 请求次数。理想情况应较高如0.8。过低可能说明容量太小或数据局部性差。missRate()缓存未命中率。1 - hitRate。与命中率相对。loadSuccessCount()成功加载新值的次数。loadExceptionCount()加载新值抛出异常的次数。异常率过高需检查CacheLoader.load逻辑的稳定性。totalLoadTime()加载新值花费的总时间纳秒。可计算平均加载时间。加载时间过长是性能瓶颈。evictionCount()因容量或过期策略被自动驱逐的条目总数。如果持续很高说明缓存容量可能不足频繁换入换出。averageLoadPenalty()平均加载耗时纳秒。直接反映load方法的性能。调优步骤记录基线在应用压力平稳时记录一套CacheStats数据作为基线。压力测试模拟生产流量进行压测。分析指标如果hitRate很低且evictionCount很高考虑增大maximumSize。如果averageLoadPenalty很高需要优化load方法如优化SQL、增加二级缓存。如果loadExceptionCount不为0需要增强load方法的健壮性考虑降级策略。调整参数根据分析调整容量、过期时间、刷新时间等参数再次压测验证。5.4 线程池与异步刷新如前所述实现真正的异步刷新需要重写reload方法并使用线程池。这里给出一个更工程化的示例import com.google.common.util.concurrent.ListenableFuture; import com.google.common.util.concurrent.ListeningExecutorService; import com.google.common.util.concurrent.MoreExecutors; import java.util.concurrent.Executors; public class AsyncRefreshCache { private final ListeningExecutorService refreshExecutor MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(5)); private final LoadingCacheString, String cache; public AsyncRefreshCache() { this.cache CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) .refreshAfterWrite(1, TimeUnit.MINUTES) .build(new CacheLoaderString, String() { Override public String load(String key) { return fetchFromSource(key); // 同步加载 } Override public ListenableFutureString reload(String key, String oldValue) { // 关键将同步的load操作提交到线程池返回Future return refreshExecutor.submit(() - fetchFromSource(key)); } }); } private String fetchFromSource(String key) { // 模拟耗时的数据获取 try { Thread.sleep(1000); } catch (InterruptedException e) { /* ... */ } return data_for_ key; } }注意事项这个自定义的线程池refreshExecutor需要根据业务量合理设置大小并在服务关闭时妥善关闭 (shutdown())否则会造成线程泄漏。5.5 Guava Cache不是银弹最后必须清醒认识到Guava Cache的局限性它是本地缓存数据只在单个JVM进程中有效。在分布式环境下你需要处理缓存一致性问题如使用Redis并配合发布订阅或者干脆直接用分布式缓存。它基于JVM堆内存缓存容量受限于JVM堆大小。存储大对象如图片、文件流需谨慎可能引发Full GC。持久化Guava Cache不提供持久化到磁盘的功能。应用重启缓存就没了。如果需要持久化需要考虑其他方案或在应用启动时预热缓存。因此它的最佳定位是分布式缓存如Redis之前的一道高性能、防穿透的本地屏障或者用于缓存那些与机器实例绑定、无需全局一致的数据如本地计算的中间结果、短时间内有效的锁状态等。理解边界才能用好工具。
