aty

guava cache很适合做进程内的缓存，本文先学习下它的缓存统计功能，需要使用recordStats()打开缓存统计功能。有一点需要注意下：可以通过修改底层map给缓存添加数据，也可以获取数据。通过map获取数据，不会影响缓存统计；通过map添加数据，会影响evictionCount。

实际开发中需要做入参校验的情况比比皆是，比如开发一个rest接口，肯定要对参数各种校验，防止错误的输入导致程序出错。我们可以使用Preconditions(前置条件)，这样我们自己代码中就不会出现大段的if代码了。Preconditions类似我们写junit单元测试或者spring中的assert。

对于开发过网络应用程序的程序员来说，重试并不陌生，由于网络的拥堵和波动，此刻不能访问服务的请求，也许过一小段时间就可以正常访问了。随着重试逻辑的不断变化，上面代码会越来越复杂。而且重试逻辑，其实是各个模块是差别不大的。最近遇到2个开源项目，都是将重试代码封装成专门的工具，方便使用，比如guava-retrying和spring-retry。

前面我们介绍了如何通过RetryerBuilder构造一个Retryer对象，现在我们学习下如何使用 Retryer.call()。这个API很重要，对于这个方法的入参、返回值、可能抛出的异常要了解清楚。入参：很简单，就是一个实现了业务逻辑的Callable对象；返回值：某次尝试成功后，Callable的返回值。我们主要关注下可能的异常：RetryException和ExecutionException。ExecutionException产生：传入的Callable执行过程中产生了异常，但是我们在构建Re

AttemptTimeLimiter和guava的TimeLimiter基本是一样的，是为了限制某个任务的执行时间。比如我希望一个Callable任务执行时间不超过5s，如果超过抛异常TimeoutException。

当发生重试之后，假如我们需要做一些额外的处理动作，比如发个告警邮件啥的，那么可以使用RetryListener。每次重试之后，guava-retrying会自动回调我们注册的监听。可以注册多个RetryListener，会按照注册顺序依次调用。

什么是阻塞策略呢？通过前面的学习，我们知道guava-retrying是可以设置2次重试的时间间隔的。比如第一次失败后，需要等待200ms再开始第二次尝试，也就是说线程需要等待200ms。实现200ms等待有多种方式，比如通过sleep方式，比如通过自旋的方式，比如锁、wait等多种控制手段，这其实就是并发策略。guava-retrying默认是使用睡眠方式来实现阻塞的。

noWait失败后立刻重试，fixedWait间隔固定时间之后重试，WaitStrategies.randomWait间隔随机时间后重试，incrementingWait增量重试，fibonacciWait按照斐波那契数列重试，exponentialWait按照指数递增(2的n次方)来重试，exceptionWait根据抛出的异常来决定等待的时间长短，join组合多个重试间隔逻辑。

当我们重试到一定阶段的时候，需要终止重试过程，比如重试了n次或者重试了n秒等。StopStrategies.stopAfterAttempt(n)：在重试了n次后终止，这个实际中最常用。StopStrategies.neverStop()：从不终止，一直重试，没有什么实际用处。StopStrategies.stopAfterDelay(10, TimeUnit.SECONDS)：一直重试，指定时间过后终止。guava-retrying提供了StopStrategy接口，我们可以实现自己想要的终止逻辑。

retryIfException，抛出runtime异常、checked异常时都会重试，但是抛出error不会重试。retryIfRuntimeException只会在抛runtime异常的时候才重试，checked异常和error都不重试。retryIfExceptionOfType允许我们只在发生特定异常的时候才重试，比如NullPointerException和IllegalStateException都属于runtime异常。上面我们看到了重试条件都是在发生异常的时候，实际上有时候没有发生异常，但是

真正加载数据的那个线程一定会阻塞，我们希望这个加载过程是异步的。这样就可以让所有线程立马返回旧值，在后台刷新缓存数据。refreshAfterWrite默认的刷新是同步的，会在调用者的线程中执行。我们可以改造成异步的，实现CacheLoader.reload()。

使用Guava确实可以做到：对于同一个key，无论有多少请求，都只会允许一个线程去加载数据。但是也有一个很致命的缺陷：上面8个线程中，有一个线程实际去加载数据，其余7个线程都被阻塞了。如果能做到，当一个线程去加载数据，其余线程发现这个数据正在加载中，那么直接读取老的数据，这样就不会阻塞了。既然是缓存，读取旧一点数据也没有多大问题，却可以提高系统吞度量。

1、通过put或putAll手动向Cache中添加数据，guava不缓存value是null的key。我们可以在系统启动的时候，就将某些数据手动放入缓存中，这样就可以避免系统启动后，第一个用户访问缓存不能命中的情况。2、通过getIfPresent/getAllPresent/get读取缓存中的数据。3、如果明确知道某些缓存无用，我们可以通过invalidate/invalidateAll删除。4、通过调用cleanUp执行缓存清理操作，比如删除过期的key。

spring+mybatis+druid数据源+sharding-jdbc分库分表

guava的容量管理，有4种方式可以将数据从缓存中移除。有的时候，我们需要在缓存被移除的时候，得到这个通知，并做一些额外处理工作。这个时候RemovalListener就派上用场了。监听器有几个特点需要注意下：1、默认情况下，监听器方法是被同步调用的（在移除缓存的那个线程中执行）。2、创建cache的时候只能添加1个监听器，这个监听器对象会被多个线程共享，所以如果监听器需要操作共享资源，那么一定要做好同步控制。3、监听器中抛出的任何异常，在被记录到日志后，会被guava丢弃，不会导致监听器不可用。

内存空间是有限的，一些不用的缓存数据需要及时清除，否则容器导致内存溢出。guava最简单一种管理方式是：基于缓存数据个数，让缓存条目始终不能超过一个上限。guava还提供基于权重的容量管理，相当于是让不同的缓存项占用不同的存储空间。最后guava还提供了基于引用的回收策略，CacheBuilder.weakKeys()、CacheBuilder.weakValues()、CacheBuilder.softValues()。当JVM回收弱引用指向的对象之后，会将弱引用加入到ReferenceQueue。通过轮

缓存一般设置的都有过期时间，如果我们写单元测试代码需要验证这个功能（缓存过期，自动删除）。假如设置的过期时间是1个小时，我们来验证1h后缓存是否被删除，那我们总不能让单元测试代码运行1个小时吧。总之，ticker就是用来做测试用途，能够让我们改变时间源，模拟任何我们想要的时间流逝效果。

在大型集群和分布式应用中，配置数据不宜分散到集群结点中，应该集中起来统一管理。本文主要介绍如何使用config toolkit这个开源工具。