# 最佳实践用法
## `refreshAfterWrite` 策略 和 `@Cacheable(sync=true)`同步
期望：
利用`refreshAfterWrite`的定时刷新特性让缓存项保持可用。但请注意：缓存项只有在被检索时才会真正刷新。
保证在高并发场景下的性能和避免出现缓存击穿的情况。
注：`refreshAfterWrite`要求`Cache`必须是`LoadingCache` ，也就是要自定义`CacheLoader`。
```java
public class CustomCacheLoader implements CacheLoader {
@Nullable
@Override
public Object load(@NonNull Object key) throws Exception {
logger.info("[CustomCacheLoader] direct return, key={}, value=null", key);
return null;
}
}
```
问题：
原本是想着直接在Cache.get(key)中调用LoadingCache.get(key)来利用`refreshAfterWrite`的特性。
但是验证下来发现由于CustomCacheLoader.load()返回的是null，所以在缓存项过期的场景下获取数据时每次都会再次去执行具体的业务方法加载数据，并put到缓存中。
分析：
该问题的本质，在于CustomCacheLoader.load()直接返回了null，而没有返回具体的业务数据。
也就是只要CustomCacheLoader.load()返回了具体的业务数据就可以利用到`refreshAfterWrite`的特性。
所以可以基于这个点进行突破。（关键在于拿到具体的业务方法method）
方案：
经研究和分析，Cache.get(key, Callable)方法的Callable就是加载数据的业务方法。
所以重写方法 Cache.get(key, Callable)的逻辑，将Callable包装到CacheLoader中，来达到实现不同缓存调用不同的加载数据逻辑的目的。
但是此方案有一个不好的点，其破坏了spring cache `@Cacheable(sync=true)`同步的概念(只有一个线程加载数据，其他线程均阻塞)。
也就
