最近运维转发过来一封线上告警邮件，大概是说，我们负责的系统线上环境有一个接口隔一段时间就频繁报错，但持续十分钟左右就自动恢复了。从监控工具看到，每次报错出现时，都是同一台实例报出来的，此时其他实例是正常的，但下一次可能是另一台实例出现相同的问题，非常奇怪。

问题特点

收到这个邮件，我梳理了一下问题的特点：

1. 不定期出现，出现时间点没有规律，业务高峰期更多一些
2. 一次持续十分钟左右
3. 每次出问题的都是同一台实例，与此同时其他实例正常
4. 每一台实例都可能出问题

---

问题分析

之后看了问题接口的逻辑，是从 db 查询一批资讯的数据，因为调用量比较大，所以设计了二级缓存。基本思想是先使用 redis 作为集中一级缓存，再使用 ehcache 作为本地二级缓存，若两级缓存都没有命中，再查询 db。与此同时，还有一个定时任务每10分钟定期把 db 的数据刷新到 redis 中，避免请求直接访问db。

根据问题特点，初步猜测问题很可能是出现在 ehcache 本地二级缓存中，因为若是代码逻辑有问题或者 redis 出现问题，应该所有实例同时都会有问题才对。

通过线上 error 日志和追踪工具分析发现，报错点是某一个字段报 NullPointerException，诡异的是，这个字段是受数据库查询条件约束的，正常情况下根本不可能为空。

-- 以下SQL查询结果的 item 字段不可能为空
SELECT t.* FROM info_table t
WHERE t.item like '05%';

之后在又一次复现时，查询了当时 db 和 redis 的数据，确定了该字段确实不为空，那么问题很明显只能出在 ehcache 本地缓存中了。此时另一位开发同事提醒我，这个缓存不仅仅是一个接口在使用，其他接口也可能用到。

于是问题原因就很明显了：其他接口拿到ehcache缓存的数据后，把缓存里的数据改掉了，导致这个接口从缓存中拿到了错误的数据。之后，定时任务又把正确的数据刷进缓存中，于是接口又自动恢复正常了。

---

问题原因

走查代码发现，确实有另一个接口拿到ehcache缓存的数据后把数据改掉了，于是乎，暂时先把该缓存对象的开关关闭（还好当初开发时设计了开关），之后排期整改：从 ehcache 取出缓存数据后，如果要对数据进行修改，必须先进行一次深拷贝。

至于深拷贝和浅拷贝的问题，之前也在 Java中的浅拷贝和深拷贝 这篇文章中分享过了。

---

从本地缓存和集中缓存取数据的区别

我们知道，在 Java 中，在方法中声明的变量和引用都是在栈中分配的，不存在线程安全问题，除非通过参数传递进来或者直接使用类变量，才可能导致线程安全问题（一个线程访问的数据被另一个线程改了）。平时的开发中，从 redis 和数据库取数据，取出来的数据也不用担心线程安全问题。

public List<Info> get1(){
    List<Info> list = jedisUtils.get("info");
}

public List<Info> get2(){
    List<Info> list = jedisUtils.get("info");
}

像上面的例子，两个线程分别通过 get1() 和 get2()从 redis 取同一份数据，取出来的两个 list 是两份一模一样的数据，在堆内存中有两个一样的对象，不会互相影响。但同样的场景，换到从 ehcache 取就不一样了。

public List<Info> get1(){
    List<Info> list = cache.get("info");
}

public List<Info> get2(){
    List<Info> list = cache.get("info");
}

从 ehcache 取出来的数据，如果你修改了 get1() 列表里面的数据，get2() 列表里的数据也会被修改，因为他们本质上是指向堆里的同一个对象。这也是为什么要用本地缓存的原因之一，减少重复内存占用，但如果开发时一不小心，修改了缓存里的对象，就会栽进坑里。

---

引申：缓存和CAP原理

最近负责的这个项目的特点是接口访问量比较大，但提供的是一些产品和资讯的信息，对一致性的要求没有很高。所以很多接口都采用了 redis一级集中缓存 + ehcache二级本地缓存 + 定时任务定时刷新缓存 的方案。

使用本地二级缓存的优点是明显的，第一是减少网络传输开销，第二是减少一份数据多个地方使用时的内存占用（前提是不要修改），第三是一定程度减少缓存穿透问题。

但是如果我们在一个需要强一致性的场景中，那么直接使用集中式缓存可能会更好一点。如果非要加上本地缓存，要么用定时轮询+版本号的方式刷新本地缓存，要么使用消息队列主动通知，但这些手段最多也只能达到准实时，根据 CAP 原理，鱼和熊掌不可兼得。

说到 CAP 原理，我看过比较好的一篇文章是 CAP理论该怎么理解？为什么是三选二？为什么是CP或者AP？ ，可以作为引申阅读。