【躲坑篇】notifyElementExpired缓存过期事件没有准时触发？这个坑你也会踩

众所周知，Ehcache这个缓存框架是hibernate的缓存的默认缓存插件。我对hibernate是非常膜拜的，爱屋及乌，我也非常信任Ehcache，经常作为我的应用缓存层。但是，最近却给他坑了一把。

你以为你写缓存过期事件（notifyElementExpired方法）按时触发了？
其实，并没有！

为什么我辛辛苦苦实现的notifyElementExpired方法没有被调用呢？

下面我们先来看看EhCache源码

的官方注释：

// FileName: net.sf.ehcache.event.CacheEventListener.java
/**
     * Called immediately after an element is <i>found</i> to be expired. The
     * {@link net.sf.ehcache.Cache#remove(Object)} method will block until this method returns.
     * <p/>
     * Elements are checked for expiry in ehcache at the following times:
     * <ul>
     * <li>When a get request is made
     * <li>When an element is spooled to the diskStore in accordance with a MemoryStore
     * eviction policy
     * <li>In the DiskStore when the expiry thread runs, which by default is
     * {@link net.sf.ehcache.Cache#DEFAULT_EXPIRY_THREAD_INTERVAL_SECONDS}
     * </ul>
     * If an element is found to be expired, it is deleted and this method is notified.
     *
     * @param cache   the cache emitting the notification
     * @param element the element that has just expired
     *                <p/>
     *                Deadlock Warning: expiry will often come from the <code>DiskStore</code>
     *                expiry thread. It holds a lock to the DiskStorea the time the
     *                notification is sent. If the implementation of this method calls into a
     *                synchronized <code>Cache</code> method and that subsequently calls into
     *                DiskStore a deadlock will result. Accordingly implementers of this method
     *                should not call back into Cache.
     */
    void notifyElementExpired(final Ehcache cache, final Element element);

从注释里面，我们可以发现这个方法触发有三种情况：

第一种情况：当有主动线程调用Ehcache的get方法调用的时候，这时候才会触发notifyElementExpired。

什么意思呢？举个例子，假如你的环境是SpringBoot + Ehcache ,使用@Cacheable注解

 @Cacheable(value="wxSessionUser", key="#userOpenId")
 @Override
 public SessionUser getSessionUser(String userOpenId) {
  //你的业务代码，你自己自由发挥吧！

  return sessionUser;
 }

当你在业务层进行调用这个方法的时候

  @Override
 public AutoReplyMessage findByEvent(XmlMessageVO receivedMsg) {
  // TODO Auto-generated method stub
  String userOpenId = receivedMsg.getFromUserName();
  SessionUser  sessionUser = userMstService.getSessionUser(userOpenId);
    //下面还有一堆代码，自己想象一下
  }

SessionUser  sessionUser = userMstService.getSessionUser(userOpenId);
这句代码，如果有缓存，就会调用缓存。如果没有缓存，就会直接拿DB，然后，再放到缓存里面。如果这个时候，当前这个sessionUser已经超出配置的timeToLiveSeconds时间，这个时候才会真正触发notifyElementExpired方法。

但是，这个时候可能已经过期很久很久，不一定是一到原先设置的最大存活时间，就会马上触发notifyElementExpired方法，而是，等待用户线程主动调用get Cache的方法才去检测缓存是否过期！

说明了什么？坑爹的Ehcache竟然没有另外一条独立的线程主动去检查缓存元素是否过期！！！那么，实现notifyElementExpired方法的意义是什么？字面上说是过期触发，但是，要等到下一次get Cache方法才检测到元素是否过期？这样不就是造成了很大时间差了吗？可能我三五个小时才有一次get  Cache动作，那么，我就要三五个小时之后，才能知道这个Cache Element在三个小时之前就死了吗？

第一种情况说到这里吧，下面看看第二种情况，看看Ehcache有没有补锅？

第二种情况：当达到maxElementsInMemory最大值的时候，或者内存不足，EhCache就会根据memoryStoreEvictionPolicy设置的回收缓存策略把Cache Element往硬盘存储

我去！竟然要我达到最大值，内存转硬盘那时候，才开始主动检测缓存元素是否过期。如果检测到元素已经过期，那就不往硬盘里面捅了。我无语在这里，如果我把maxElementsInMemory设为一万，那么，我不就要等到内存元素填满，才能触发notifyElementExpired方法？？？如果我三天才能满一万，那么，我三天之后，才知道三天前就已经失效的缓存元素？不知道你有没有觉得坑，但是，我觉得挺坑的！

第三种情况：当到了diskExpiryThreadIntervalSeconds时间，检查过期元素的专用线程开始检查在硬盘上的缓存元素是否过期。

没错！你看清楚，是硬盘上的元素检查，不是内存的元素。只针对硬盘上的所有缓存元素进行检查一遍，发现有过期的，将主动删除，并且，触发notifyElementExpired方法进行通知。还是没有符合我的要求，我的要求是在内存里面的元素也要主动并且按时准时触发notifyElementExpired方法通知我，让我做缓存元素过期的事情啊！

解决方案

最好是你自己写一个独立的后台线程，自己设置个时间定期执行cache.getKeysWithExpiryCheck();这样就会定时检查过期元素，虽然也做不到实时触发notifyElementExpired方法通知我，但是，也能减少了很大的时间差。

最后，我说一下哈。

其实，我个人不推荐你在notifyElementExpired方法里面做一些小动作的，不推荐大家用后台线程从Cache中收集和删除过期的元素，因为这会影响Cache的性能（但如果内存使用更重要，那你就要自己掂量掂量了，权衡一下吧）。

我的写作风格:
用原作者的注释去说代码，让你仿佛跟代码原创者对话一般。

觉得这篇文章对你有用，就请您点赞分享收藏,顺路点"在看"呗！我们下期再会!