本文探讨caffeine缓存中`getifpresent`意外返回null的问题，主要归因于`weakkeys()`、`weakvalues()`的误用导致条目被垃圾回收，以及缓存实例生命周期管理不当（非`static final`）导致的缓存重置。教程将详细解释这些机制，并提供正确的配置与管理策略，确保缓存按预期工作，从而避免数据意外丢失。
Caffeine是一个高性能的Java本地缓存库，广泛应用于需要快速访问和临时存储数据的场景。然而，在使用Caffeine时，开发者有时会遇到缓存中明明已存入数据，但通过getIfPresent()方法却意外获取到null的情况。这通常不是Caffeine本身的bug，而是由于对缓存的配置和生命周期管理存在误解。
核心问题分析：弱引用与垃圾回收
在Caffeine的配置中，weakKeys()和weakValues()是两个强大的选项，它们允许缓存的键或值被JVM的垃圾回收器（GC）回收，即使它们仍在缓存中。
weakKeys(): 当一个键被配置为弱引用时，如果除了缓存本身之外，没有其他强引用指向这个键对象，那么该键及其对应的缓存条目就可能在下一次垃圾回收时被清除。对于像Long这样的包装类型，虽然它们是对象，但由于其值的特殊性，通常会被JVM缓存或内部化，因此weakKeys()可能不是导致Long类型键被回收的主要原因，除非键对象本身是一个非内部化的、无其他强引用的自定义对象。
weakValues(): 这是导致缓存值意外消失的更常见原因。当一个值被配置为弱引用时，如果除了缓存本身之外，没有其他强引用指向这个值对象，那么该值及其对应的缓存条目就可能在下一次垃圾回收时被清除。这意味着，如果一个SmsData对象被创建，然后立即放入缓存，并且在应用程序的其他任何地方都没有强引用持有这个SmsData对象，那么它就可能在短时间内被GC回收，导致getIfPresent()返回null。
考虑以下原始的缓存配置：
private Cache codeCache = Caffeine.newBuilder() .expireAfterWrite(24, TimeUnit.HOURS) .weakKeys() .weakValues() .build();
当使用weakValues()时，如果SmsData对象在put到codeCache后，在方法作用域外没有被其他强引用持有，那么它就成为了垃圾回收的候选对象。JVM的GC可以在任何时候回收这些弱引用的值，从而导致缓存条目消失。
何时使用弱引用？弱引用并非一无是处。它们在某些特定场景下非常有用，例如：
缓存大型对象，但这些对象在应用程序的其他部分也有强引用，你希望当其他强引用消失时，缓存也能自动释放内存。实现元数据缓存，当元数据关联的主对象被回收时，元数据也应被回收。然而，对于大多数常规缓存场景，我们希望缓存能够强引用其值，直到过期策略生效或手动移除。因此，除非你明确理解并需要弱引用的行为，否则应避免使用weakKeys()和weakValues()。
核心问题分析：缓存实例的生命周期管理
另一个导致Caffeine缓存行为异常的常见原因是缓存实例的生命周期管理不当。如果缓存实例不是一个单例或长寿命对象，那么每次需要使用缓存时都可能创建新的缓存实例，导致之前存储的数据丢失。
考虑以下原始的缓存声明：
private Cache codeCache = Caffeine.newBuilder() // ... 配置 ... .build();
如果这个codeCache是一个普通类的实例字段，并且这个类本身是每次请求或每次操作时都会被重新创建的，那么每次创建这个类的实例时，都会创建一个全新的Cache对象。这意味着，在一个实例中put的数据，在另一个新实例中尝试get时，将无法找到，因为它们是不同的缓存实例。
存了个图
视频图片解析/字幕/剪辑，视频高清保存/图片源图提取
17 查看详情
推荐策略：对于应用程序级别的缓存，通常期望它是一个全局的、单例的资源，其生命周期与应用程序的生命周期一致。实现这一目标的方法通常有两种：
使用static final字段：将缓存声明为static final，确保它只在类加载时初始化一次，并且在整个应用程序生命周期中都只有一个实例。依赖注入（DI）框架管理：如果项目使用了Spring等依赖注入框架，可以将Caffeine Cache实例声明为一个@Bean，并设置为单例作用域。框架会负责管理其生命周期，确保每次注入的都是同一个缓存实例。
解决方案与最佳实践
基于上述分析，解决Caffeine缓存意外返回null问题的核心在于：移除不必要的弱引用配置，并确保缓存实例的生命周期管理得当。
1. 修正后的Caffeine缓存配置
首先，移除weakKeys()和weakValues()。除非有非常明确的理由和场景需要它们，否则应避免使用，以确保缓存中的值被强引用持有。
import com.github.benmanes.caffeine.cache.Cache;import com.github.benmanes.caffeine.cache.Caffeine;import java.util.concurrent.TimeUnit;// 假设 SmsData 是一个自定义的数据类class SmsData { private int sendCount; private int checkCount; public int getSendCount() { return sendCount; } public void setSendCount(int sendCount) { this.sendCount = sendCount; } public int getCheckCount() { return checkCount; } public void setCheckCount(int checkCount) { this.checkCount = checkCount; } @Override public String toString() { return "SmsData{" + "sendCount=" + sendCount + ", checkCount=" + checkCount + '}'; }}public class CaffeineCacheService { // 推荐的Caffeine缓存配置： // 1. 声明为 static final，确保缓存实例是单例且生命周期与应用程序一致。 // 2. 移除 weakKeys() 和 weakValues()，确保缓存强引用其键和值，防止被GC过早回收。 private static final Cache codeCache = Caffeine.newBuilder() .expireAfterWrite(24, TimeUnit.HOURS) // 设置写入后24小时过期 // .maximumSize(10_000) // 可选：设置最大缓存条目数 .build(); private static int currentSendCount = 0; // 示例计数器 public void storeSmsData(Long id) { SmsData data = new SmsData(); data.setSendCount(++currentSendCount); data.setCheckCount(0); codeCache.put(id, data); System.out.println("Stored: id=" + id + ", data=" + data); } public SmsData getSmsData(Long id) { SmsData retrievedData = codeCache.getIfPresent(id); System.out.println("Retrieved: id=" + id + ", data=" + retrievedData); return retrievedData; } public static void main(String[] args) throws InterruptedException { CaffeineCacheService service = new CaffeineCacheService(); Long testId = 123L; service.storeSmsData(testId); SmsData data1 = service.getSmsData(testId); // 此时应该能获取到数据 // 模拟一段时间，但未到过期时间 Thread.sleep(100); SmsData data2 = service.getSmsData(testId); // 仍然能获取到数据 // 假设另一个服务实例（但由于是static final，实际上是同一个缓存） CaffeineCacheService anotherService = new CaffeineCacheService(); SmsData data3 = anotherService.getSmsData(testId); // 仍然能获取到数据 }}
2. 缓存的存取操作
在上述修正配置后，缓存的存取操作保持不变，但其行为将符合预期：
// 存储值SmsData dataToStore = new SmsData(); // 实例化 SmsDatadataToStore.setSendCount(++currentSendCount);dataToStore.setCheckCount(0);codeCache.put(id, dataToStore);// 获取值SmsData retrievedData = codeCache.getIfPresent(id);// 此时，只要 id 存在且未过期，retrievedData 将不再是 null
总结最佳实践点：
谨慎使用弱引用：除非你明确需要并且理解weakKeys()和weakValues()的垃圾回收行为，否则应避免使用它们。对于大多数应用场景，Caffeine的过期策略（expireAfterWrite、expireAfterAccess）和容量限制（maximumSize）足以管理缓存生命周期。确保缓存实例的单例性：对于应用程序全局使用的缓存，务必将其声明为static final，或者通过依赖注入框架（如Spring的@Bean）进行单例管理，确保在整个应用生命周期中只有一个缓存实例。理解Caffeine的驱逐策略：除了弱引用，Caffeine还提供了多种驱逐策略，如基于时间的（expireAfterWrite、expireAfterAccess）和基于容量的（maximumSize）。合理配置这些策略对于维护缓存的健康和性能至关重要。测试缓存行为：在开发过程中，对缓存的存取行为进行充分的单元测试和集成测试，以验证其是否按预期工作，尤其是在并发环境或长时间运行后。
总结
Caffeine缓存的强大功能伴随着一定的配置复杂性。当getIfPresent()意外返回null时，通常是由于对弱引用机制的误解导致缓存条目被垃圾回收，或缓存实例的生命周期管理不当导致数据存储在不同的缓存实例中。通过将缓存声明为static final并移除不必要的weakKeys()和weakValues()配置，可以有效解决这些问题，确保Caffeine缓存的稳定性和可靠性。理解这些核心概念对于构建健壮且高性能的Java应用程序至关重要。
以上就是解决Caffeine缓存意外返回Null：配置与生命周期最佳实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/571367.html
微信扫一扫 
支付宝扫一扫 
