问题在于，为什么当缓存过期，你的线程会同时去数据库取数据。
我设想一下，你的缓存的过滤逻辑应该是：
检查缓存是否存在，存在则取出缓存的数据，不存在则去数据库查询。
这样的缓存设计方案，在多线程环境下，是需要做额外同步的。不做同步，有很大几率发生缓存穿透。这种穿透类似于多线程为加锁的懒汉单例访问，导致多次构建对象。如下：

static Object instance = null;

public static Object getInstance(){

      if(instance == null){

              instance = new Object();

      }

      return instance;

}

上面代码，在多线程环境下，可能会导致new Object()被执行多次。同样的道理，对于常规缓存操作：

static Map<String,Object> cache = new HashMap<String,Object>();

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){

             val =  readFromDB();

             cache.put(key,val);

      }

      return val;

}

此时，readFromDB()可能会被执行多次。
既然已经找到类比的问题，那么就按照类比为题的解决方案来解决就行，对于懒汉单例模式的多线程，通过DLC（双重校验锁定）即可解决。如下：

static voildate Object instance = null;

public static Object getInstance(){

      if(instance == null){  //第一重检验

              synchronized(App.class){  //锁定，避免其它线程同时进入，导致重复初始化

                         if(instance == null){  //第二重校验

                               instance = new Object()

                         };

              }

      }

      return instance;

}

好，延伸到Cache，由于你使用的是ehcache，ehcache本身是线程安全的Map，所以其get()操作是可以保证volidate语义的，那么，就可以如下实现：

static Map<String,Object> cache = new Cache<String,Object>();

static final int lockCount = 100;  //这里声明100个锁对象，锁对象越多，锁粒度越小，吞吐量越高

static Object[] locksForCache = new Object[lockCount ];

static{

      for(int i = 0;i<lockCount ;i++){

            locksForCache[i] = new Object();  //初始化锁

      }

}

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){  //第一重校验

             Object lock = locksForCache[key.hashCode() % locksForCache ];

             synchronized(lock){  //加锁

                       val = cache.get(key);

                       if(val == null){  //第二重校验

                           val =  readFromDB();

                           cache.put(key,val);

                       }

             }

      }

      return val;

}

这样就可以保证对于数据库的读取，只会发生一次，后续的线程将会直接读取后的数据，不会再次读取数据库。缓存穿透问题解决。

问个问题，你们请求量多大啊， 数据库都承受不了

有两种场景：一是缓存失效后，加载开销非常大；二是相关的访问量极大，虽然去数据库加载开销并不大，但是架不住访问量多。
在这两种场景下， 缓存失效（比如过期）时造成的雪崩效应是相当明显的。

一个手段是，去数据库加载的时候，只允许一个线程进去加载，先读缓存，未命中的情况下，你的loadXxxFromDB方法加个synchronized，然后在方法里再先多读一次缓存就可以。好处是实施起来比较简单，可以一定程度上缓解。但它的缺点在于，第一，如果你的服务器是一个集群，那么仍然存在不同的服务器同时加载的问题（解决办法是基于远端缓存做个分布式锁，实施起来稍微繁琐一点）；另外一个问题是，当你的一个线程在加载的时候，其它线程需要等待锁，这样这个调用的响应时间（RT）并未显著降低，如果读数据库时间较长，并且并发进入的请求又比较多，可能会出现线程池满的情况。

另外一个办法就是，有一个异步的任务，在后台自动刷，相当于预热，这样性能肯定是最好的，就是开发上麻烦点。

我在我开发的JetCache中实现了自动刷新，不过尚未支持ehcache（当前只支持tair和redis）：
https://github.com/alibaba/jetcache/wiki/AdvancedCacheAPI#自动刷新缓存

使用代码如下
@CreateCache
private Cache<String, Long> orderSumCache;

@PostConstruct
public void init(){
    RefreshPolicy policy = RefreshPolicy.newPolicy(1, TimeUnit.MINUTES)
                          .stopRefreshAfterLastAccess(30, TimeUnit.MINUTES);
    userCache.config().setLoader(this::loadOrderSumFromDatabase);
    userCache.config().setRefreshPolicy(policy);
}

以上代码指定针对某个key调用get方法以后，缓存会自动每1分钟刷新一次，如果该key30分钟内没有访问，则停止刷新。在一个应用集群中，每个刷新周期内只会有一个服务器去刷新，这是通过Cache接口上的tryLock实现了排他锁定。
由于注解上的属性只能是常量，所以没法在CreateCache注解里面配置loader，就在初始化方法里面进行设置了，代码稍微多了一点，见谅。

下面再补充一下，对于分布式环境下的缓存DCLP规避缓存雪崩的实现方法：
首先，对于单个节点，缓存雪崩可以通过DCLP来规避，但是DCLP是基于锁的，锁的粒度直接影响到了出现击穿时缓存的吞吐量，所以设置一个合理的锁粒度，是提高效率的关键（关于DCLP缓存中的“锁粒度”概念，可以看我上面的回答贴出的代码部分）。
对于分布式缓存，可以将DCLP缓存进行细化，细化方式就是hash(key)%cacheCount，那么，相同key就会分发到同一个缓存实例上，再在每个缓存实例中加入DCLP，就可以从全局上规避缓存雪崩，并且节点间也不需要额外的同步锁进行同步。
更重要的是，多节点DCLP可以严格保证，发生穿透时，数据只会被读取一次。
好，前面说过，单个DCLP缓存节点，吞吐量跟锁粒度有关系。那么多节点DCLP缓存，吞吐量就跟缓存数量以及锁粒度都有关系了。可以对命中率比较高的缓存节点，增大配置，降低锁的粒度（甚至可以再一次进行hash分片，建立基于hash的树状缓存结构），对命中率比较低的缓存节点，就可以适当降低配置。下面是一个简单的流程图：

这种缓存就比较适合与缓存比较分散的情况了。

总结一下，Key集中，可以用定时Flush，Key分散，可以用Hash。具体选用，还要结合实际情况进行分析才行。

Quote: 引用 17 楼 zs808 的回复:

下面再补充一下，对于分布式环境下的缓存DCLP规避缓存雪崩的实现方法：
首先，对于单个节点，缓存雪崩可以通过DCLP来规避，但是DCLP是基于锁的，锁的粒度直接影响到了出现击穿时缓存的吞吐量，所以设置一个合理的锁粒度，是提高效率的关键（关于DCLP缓存中的“锁粒度”概念，可以看我上面的回答贴出的代码部分）。
对于分布式缓存，可以将DCLP缓存进行细化，细化方式就是hash(key)%cacheCount，那么，相同key就会分发到同一个缓存实例上，再在每个缓存实例中加入DCLP，就可以从全局上规避缓存雪崩，并且节点间也不需要额外的同步锁进行同步。
更重要的是，多节点DCLP可以严格保证，发生穿透时，数据只会被读取一次。
好，前面说过，单个DCLP缓存节点，吞吐量跟锁粒度有关系。那么多节点DCLP缓存，吞吐量就跟缓存数量以及锁粒度都有关系了。可以对命中率比较高的缓存节点，增大配置，降低锁的粒度（甚至可以再一次进行hash分片，建立基于hash的树状缓存结构），对命中率比较低的缓存节点，就可以适当降低配置。下面是一个简单的流程图：

这种缓存就比较适合与缓存比较分散的情况了。

总结一下，Key集中，可以用定时Flush，Key分散，可以用Hash。具体选用，还要结合实际情况进行分析才行。

如果使用这种方案cache扩容就得重新缓存一次所有数据了？

Quote: 引用 5 楼 zs808 的回复:

问题在于，为什么当缓存过期，你的线程会同时去数据库取数据。
我设想一下，你的缓存的过滤逻辑应该是：
检查缓存是否存在，存在则取出缓存的数据，不存在则去数据库查询。
这样的缓存设计方案，在多线程环境下，是需要做额外同步的。不做同步，有很大几率发生缓存穿透。这种穿透类似于多线程为加锁的懒汉单例访问，导致多次构建对象。如下：

static Object instance = null;

public static Object getInstance(){

      if(instance == null){

              instance = new Object();

      }

      return instance;

}

上面代码，在多线程环境下，可能会导致new Object()被执行多次。同样的道理，对于常规缓存操作：

static Map<String,Object> cache = new HashMap<String,Object>();

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){

             val =  readFromDB();

             cache.put(key,val);

      }

      return val;

}

此时，readFromDB()可能会被执行多次。
既然已经找到类比的问题，那么就按照类比为题的解决方案来解决就行，对于懒汉单例模式的多线程，通过DLC（双重校验锁定）即可解决。如下：

static voildate Object instance = null;

public static Object getInstance(){

      if(instance == null){  //第一重检验

              synchronized(App.class){  //锁定，避免其它线程同时进入，导致重复初始化

                         if(instance == null){  //第二重校验

                               instance = new Object()

                         };

              }

      }

      return instance;

}

好，延伸到Cache，由于你使用的是ehcache，ehcache本身是线程安全的Map，所以其get()操作是可以保证volidate语义的，那么，就可以如下实现：

static Map<String,Object> cache = new Cache<String,Object>();

static final int lockCount = 100;  //这里声明100个锁对象，锁对象越多，锁粒度越小，吞吐量越高

static Object[] locksForCache = new Object[lockCount ];

static{

      for(int i = 0;i<lockCount ;i++){

            locksForCache[i] = new Object();  //初始化锁

      }

}

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){  //第一重校验

             Object lock = locksForCache[key.hashCode() % locksForCache ];

             synchronized(lock){  //加锁

                       val = cache.get(key);

                       if(val == null){  //第二重校验

                           val =  readFromDB();

                           cache.put(key,val);

                       }

             }

      }

      return val;

}

这样就可以保证对于数据库的读取，只会发生一次，后续的线程将会直接读取后的数据，不会再次读取数据库。缓存穿透问题解决。

靠谱。
我在想是不是可以使用多线程的方式来提高性能呢？

Quote: 引用 9 楼 github_39199665 的回复:

有两种场景：一是缓存失效后，加载开销非常大；二是相关的访问量极大，虽然去数据库加载开销并不大，但是架不住访问量多。
在这两种场景下， 缓存失效（比如过期）时造成的雪崩效应是相当明显的。

一个手段是，去数据库加载的时候，只允许一个线程进去加载，先读缓存，未命中的情况下，你的loadXxxFromDB方法加个synchronized，然后在方法里再先多读一次缓存就可以。好处是实施起来比较简单，可以一定程度上缓解。但它的缺点在于，第一，如果你的服务器是一个集群，那么仍然存在不同的服务器同时加载的问题（解决办法是基于远端缓存做个分布式锁，实施起来稍微繁琐一点）；另外一个问题是，当你的一个线程在加载的时候，其它线程需要等待锁，这样这个调用的响应时间（RT）并未显著降低，如果读数据库时间较长，并且并发进入的请求又比较多，可能会出现线程池满的情况。

另外一个办法就是，有一个异步的任务，在后台自动刷，相当于预热，这样性能肯定是最好的，就是开发上麻烦点。

我在我开发的JetCache中实现了自动刷新，不过尚未支持ehcache（当前只支持tair和redis）：
https://github.com/alibaba/jetcache/wiki/AdvancedCacheAPI#自动刷新缓存

使用代码如下
@CreateCache
private Cache<String, Long> orderSumCache;

@PostConstruct
public void init(){
    RefreshPolicy policy = RefreshPolicy.newPolicy(1, TimeUnit.MINUTES)
                          .stopRefreshAfterLastAccess(30, TimeUnit.MINUTES);
    userCache.config().setLoader(this::loadOrderSumFromDatabase);
    userCache.config().setRefreshPolicy(policy);
}

以上代码指定针对某个key调用get方法以后，缓存会自动每1分钟刷新一次，如果该key30分钟内没有访问，则停止刷新。在一个应用集群中，每个刷新周期内只会有一个服务器去刷新，这是通过Cache接口上的tryLock实现了排他锁定。
由于注解上的属性只能是常量，所以没法在CreateCache注解里面配置loader，就在初始化方法里面进行设置了，代码稍微多了一点，见谅。

这个对于分布式缓存下的缓存雪崩是一个相当好的解决方案，学习了！
这种方案有一点，就是，如果key的分布不是非常集中，那么有可能会导致多次无用的读数据库的情况。比方说，A命中->缓存A，那么该算法对于接下来30分钟内，A的重复访问是非常高效的。但是如果缓存key的调用顺序不是ABAABBAACGADDE这样，而是ABCDEFGAEBC，那么，就有可能导致30分钟内，ABCDEFG每分钟都会刷新一次，但是其实实际没有命中的情况。

Quote: 引用 7 楼 gongyali2005 的回复:

Quote: 引用 5 楼 zs808 的回复:

问题在于，为什么当缓存过期，你的线程会同时去数据库取数据。
我设想一下，你的缓存的过滤逻辑应该是：
检查缓存是否存在，存在则取出缓存的数据，不存在则去数据库查询。
这样的缓存设计方案，在多线程环境下，是需要做额外同步的。不做同步，有很大几率发生缓存穿透。这种穿透类似于多线程为加锁的懒汉单例访问，导致多次构建对象。如下：

static Object instance = null;

public static Object getInstance(){

      if(instance == null){

              instance = new Object();

      }

      return instance;

}

上面代码，在多线程环境下，可能会导致new Object()被执行多次。同样的道理，对于常规缓存操作：

static Map<String,Object> cache = new HashMap<String,Object>();

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){

             val =  readFromDB();

             cache.put(key,val);

      }

      return val;

}

此时，readFromDB()可能会被执行多次。
既然已经找到类比的问题，那么就按照类比为题的解决方案来解决就行，对于懒汉单例模式的多线程，通过DLC（双重校验锁定）即可解决。如下：

static voildate Object instance = null;

public static Object getInstance(){

      if(instance == null){  //第一重检验

              synchronized(App.class){  //锁定，避免其它线程同时进入，导致重复初始化

                         if(instance == null){  //第二重校验

                               instance = new Object()

                         };

              }

      }

      return instance;

}

好，延伸到Cache，由于你使用的是ehcache，ehcache本身是线程安全的Map，所以其get()操作是可以保证volidate语义的，那么，就可以如下实现：

static Map<String,Object> cache = new Cache<String,Object>();

static final int lockCount = 100;  //这里声明100个锁对象，锁对象越多，锁粒度越小，吞吐量越高

static Object[] locksForCache = new Object[lockCount ];

static{

      for(int i = 0;i<lockCount ;i++){

            locksForCache[i] = new Object();  //初始化锁

      }

}

public static Object getValue(String key){

      Object val = cache.get(key);

      if(val ==  null){  //第一重校验

             Object lock = locksForCache[key.hashCode() % locksForCache ];

             synchronized(lock){  //加锁

                       val = cache.get(key);

                       if(val == null){  //第二重校验

                           val =  readFromDB();

                           cache.put(key,val);

                       }

             }

      }

      return val;

}

这样就可以保证对于数据库的读取，只会发生一次，后续的线程将会直接读取后的数据，不会再次读取数据库。缓存穿透问题解决。

靠谱。
我在想是不是可以使用多线程的方式来提高性能呢？

同意，另外缓存穿透问题其实结论还是共享与独享的问题，我们的缓存设计会考虑执行的顺序和优先级别。