不羡鸳鸯不羡仙，一行代码调半天。原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。
缓存，在高并发的应用中，用的那是相当多。为什么？就因为I/O实在是慢！为了解决不同组件之间的速度差，大家都寄希望于加入一个中间层，期待产生一些魔幻的事。
就拿Redis来说，火的就一塌糊涂，但中间会产生很多数据同步和数据一致性问题。有的牛x公司嫌烦，同时有钱，干脆干掉缓存后面的DB，直接把所有的数据放在了缓存上。哦不，这时候缓存已经不叫做缓存，应该叫做快存，因为它最终是要通过rdb落地的。
看到这里，先不要怀疑事实的正确性。有些公司的业务，确实不需要什么关系型数据库，一个redis就能玩得转。
闪电缓存场景
那闪电缓存又是何方神圣？实在不好意思， 这个名词，是xjjdog自创的。
它用在下面的场景之中。
- 一份数据，通过耗时的请求获取之后，会在极短的时间内，再次被用到。
- 业务对数据的一致性要求不是特别强烈，但也不是无底线忍受。
- 内存的空间有限，不适合把大量数据放在内存中。
- 数据的使用跨方法、跨代码块、甚至跨线程，只在时间概念上有关联
这个时候，我们就可以将数据缓存一小段时间，尽量在下次的使用的时候，从这个时间极短的缓存中获取。
srping-data-jpa背后的Hibernate一级缓存，在同一session下的数据被自动缓存，可以变相的看作是闪电缓存的一种实现。不过人家叫一级缓存，显得更高大上一些，应用也更局限一些。
Java有多种缓存数据的方法，也有不同的生命周期。你可以想一下Session中的数据该如何存取，也可以想一下Java框架中各种各样的Context，都是为了共享数据。
实现方式
闪电缓存，在Java中其实是有多种方式的，也有各种各样的优缺点。
ThreadLocal
第一种方式，就是ThreadLocal。拿最常用的Spring来说，它事务管理的传播机制，就是使用ThreadLocal实现的。
我可以在数据第一次被获取的时候，使用set方法给它设置一个值。然后在最后一个操作用的使用，把它remove掉，变相的实现请求级别的闪电缓存。（为什么要remove？因为在线程池中可能会有复用的问题）
但由于ThreadLocal是线程私有的，所以它不能够跨线程。上面Spring的事务传播机制是不能够跨线程的，我们的闪电缓存也是不能够跨线程的。
要想做到线程透传，也不是不可能。可以参照xjjdog以前的一篇文章。
这就决定了ThreadLocal的应用场景有限。但它还有其他两个硬伤：
- ThreadLocal的生命周期不好管理，何时生成，何时销毁，都是问题
- ThreadLocal使用自定义的
ThreadLocalMap。它虽然叫Map，但却没有实现Map的接口，它使用开放寻址（遇到冲突，依次查找，直到空闲位置）的方法，这种方式是非常低效的
综上三点，ThreadLocal这个方案其实并不太好。
普通Cache加过期时间
我们可以变换一下思路，使用普通的Cache，然后给它一个超短的缓存时间，那么就可以变相的实现闪电缓存的功能。
实现也是非常简单的。比如，下面几行代码，就是一个对对象缓存了3秒的例子。
LoadingCache<String, String> lc = CacheBuilder
.newBuilder()
.expireAfterWrite(3,TimeUnit.SECONDS)
.build(new CacheLoader<String, String>() {
@Override
public String load(String key) throws Exception {
return slowMethod(key);
}
});
在这3秒之间，系统中所有用到这个数据的请求，都可以达到复用的效果。这对于并发量非常高的应用来说，减少的请求量可能是数量级的。
我曾经就做过一个对用户基本信息的优化，把对用户服务的请求量从8w/s，降低到1000/s，一度让负责服务的同学以为上游业务当机了。
End
技术通常都是工具，只有真正用到业务场景中，才有它的价值。闪电缓存这个概念本身没有什么神奇的，它的最优实现方式，竟然是普通的Cache加极短的过期时间。
技术本身是件非常简单的事情，但想到它应用的场景，却是比较难的。事实上，我已经把这个概念做到了我的ppt上，展现的时候大家比较迷惑，以为是什么高大上的东西，我自热也不好意思戳破这层窗户纸，就让它继续神秘下去吧。
如今xjjdog告诉你了，要保密哦。
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。
