一头扎进caffeine cache的大坑

一头扎进caffeine cache的大坑

caffeine号称性能做好的本地cache,最近想实践一下学的东西，写个小demo，就用caffeine作为本地缓存缓存一下用户的token，然后配置大概如下：

 private static final Cache<String, String> userTokenCache = Caffeine.newBuilder()
            // 数量上限
            .maximumSize(10000)
            // 过期机制
            .expireAfterAccess(30, TimeUnit.MINUTES)
            // 弱引用key
            .weakKeys()
            // 弱引用value
            .weakValues()
            .build();
     @Bean("userTokenCache")
    public Cache<String,String> userTokenCache(){

        return userTokenCache;
    }

测试的时候发现当前请求生成token放入userTokenCache后 ，下一个请求根据同样的token拿不到缓存数据，最开始怀疑是多线程共享了userTokenCache 这个变量，导致线程1放入的数据线程2无法获取到，后来把final 关键字换成volatile关键字后发现依旧不行。最后突然发现这段代码(我承认这个Caffeine的初始化代码是抄来的)：

   			// 弱引用key
            .weakKeys()
            // 弱引用value
            .weakValues()

这个的话是把key和value都设置成弱引用，弱引用在JVM的下一次GC中会被回收。于是打开GC日志输出，在日志中发现了一行：

[GC (Allocation Failure)  82226K->20184K(208896K), 0.0064046 secs]

猜测是这个问题，于是将

   			// 弱引用key
            .weakKeys()
            // 弱引用value
            .weakValues()

删除，再次测试，可以获取到token了，已经80%确定是这个问题了。后来为了论证这个问题，决定在放缓存前后打印系统时间戳，GC日志中也输出时间戳，做一下对比。但是只获取到了GC时间为相对于系统启动的时间，而没有获取到GC的系统时间戳，这个问题只停留在了80%的确定上，如果哪路高手看到了这个问题，还请留下验证方法，把这个问题100%证明一下。