并发,缓存与guava

作为一个已经用了很长时间缓存的javaer,老实说到今天为止才真正知道缓存该怎么用。为什么这么说呢?考虑如下代码:

是不是很熟悉?典型的缓存客户端代码,但是这段代码是有问题的。问题不在cache,而在于这段代码本身。考虑如下的场景:

线程A和线程B用同一个key访问get方法。
线程A发现缓存缺失,即cache返回null,开始执行compute。
线程B在线程A执行compute的时候同样发现缓存缺失,开始执行compute。
线程A执行完毕,放入缓存。
线程B执行完毕,放入缓存。

发现问题了么?除了两次放入,compute还被执行了两次。这样就违背了缓存的要求,即一次计算后多次复用。用并发的说法,不满足原子性。
你可能会说cache满足原子性,理论上客户代码也应该是满足原子性的。事实上却并不是这样,compute执行时间越长,并发请求越多,越有可能出现违背原子性的情况。

那么解决方法是什么?
最简单也是最古老的方式是在方法签名或者是cache上增加synchronized,也就是有名的监视器模式。增加同步关键字之后客户代码满足了原子性,不再出现重复计算的情况了。但是不同关键字的计算被串行,高并发下性能会变得很差。

让我们再看这段代码。容易违背原子性的代码是compute和put。如果compute能在极短时间内返回,就能极大地降低违背原子性的机率。问题在于现实情况compute不会那么快返回,否则就没有使用cache的必要了。但这提供给我们一个思路:线程A在compute开始执行时在缓存中占个位,这样线程B就不会同时执行compute,并且可能等待A计算结束后的结果。在Java这其实就是Future做的事情。在缓存中放入Future。线程A等待Future的结果。线程B根据key获取到了Future引用,同样开始等待计算结果。

注意:Memoier2是去除同步关键字后使用ConcurrentHashMap。原因除了HashMap不能直接用于并发环境之外,cache组合操作的原子性仍旧依赖cache自身的原子性。所以Memoier3使用的是ConcurrentHashMap。

问题到这里结束了?还没有,刚才提到:线程A放入了Future,线程B获取到Future。问题在于高并发下,线程B可能在A放入Future之前调用cache的get方法,这样仍旧会引起重复的计算。针对这种问题,put可能无法满足我们的要求,我们可能需要ConcurrentHashMap相对于HashMap额外提供的方法putIfAbsent提供的原子性。

不管前面get方式怎么执行,最坏的情况是线程A和B都缓存缺失,尝试往缓存中放入Future。这时线程A和B都会调用putIfAbsent。putIfAbsent的语义是如果不存在就放入。不管线程A和B调用顺序如何,总有一个线程得到另外一个线程的结果,另外一个线程得到之前的值null。这样我们可以依赖这个确定的条件撰写如下代码:

注意:实际代码还要考虑Future执行失败的情况,所以会有一个循环

关于putIfAbsent的作用建议仔细品味下。

guava

以上所有缓存代码都不涉及过期、失效等问题。原书《Java并发编程》并没有讨论这些特性。不过个人认为足够了,大部分缓存产品都有过期和失效的特性,除了ConcurrentHashMap。那如果你需要基于ConcurrentHashMap开发内存缓存,又不想让缓存的对象序列化以满足某些缓存产品的要求的话,建议试试个google的guava中的CacheBuilder。(当然你也可以基于weakreference, softreference自己写)

以下是常规代码:

个人认为和一般缓存代码不同的是,创建时提供关键字和缓存对象的转换函数是一个很聪明的做法,当然只适合于单一缓存内容的场景。CacheBuilder中个人认为比较有用的是:

设置最大数量和过期时间。过期时间提供after read, after write两种策略。

非简单计算场景使用callback延迟计算。类似future。

移除监听器,可以用来打日志。当然,移除依赖过期策略:guava的缓存并不会立即移除,除非你调用cleanUp。

以上就是正确使用缓存时你需要了解的一些东西,同时请告诉自己:Concurrency is hard.

参考资料