四种缓存的避坑总结

背景

分布式、缓存、异步和多线程被称为互联网开发的四大法宝。今天我总结一下项目开发中常接触的四种缓存实际项目中遇到过的问题。

JVM 堆内缓存

JVM 堆内缓存因为可以避免 Memcached、Redis 等集中式缓存网络通信故障问题，目前还在项目中广泛使用。

堆内缓存需要注意 GC 的问题。假如我们的设计是定时的从远程来拉取数据更新本地缓存。一定要注意两点：第一不要全量拉取覆盖，第二不要把一个大对象整体替换为新对象。

先说全量拉取覆盖。全量拉取会有很大的网络开销，会造成网络流量尖刺。有人说没事，我们带宽很足，内网访问，不怕不怕。但是稳定性需要修炼的一项是削峰填谷。让系统在平稳的环境中运行。不然，在拉取大缓存新数据的数据突然来了个突发流量？根据墨菲定律，凡是有几率会发生的事情就一定会发生。编程需谨慎。

再说大对象整体替换的问题，这会造成 GC 问题。伪代码如下：

List<POJO> oldList = initList();
public void refresh() {
      List<POJO> newList = dataFromNetworkService.getAll();
      oldList = new List();
      for(POJO pojo : newList) {
          oldList.add(pojo);
      }
}

如果从网上拉取的数据和在缓存里存储的数据，对象类型没有发生改变。引起的转换开销还稍微小点。因为比如对象 POJO 存在一个列表里。这个列表虽然很大，但是里面存的都是对象的引用。实际的 POJO 并没有发生变化。上面伪代码虽然新建一个 List 对象，遍历添加新对象比直接 oldList=newList 要傻些。但是遍历过程实际上 POJO 对象没有发生改变。所以这里影响 GC 的只是 oldList 这个对象（不包括从网络上拉取回来数据的过程）。

但是如果代码这样写：

List<POJO2> oldList = initList();
public void refresh() {
      List<POJO1> newList = dataFromNetworkService.getAll();
      oldList = new List();
      for(POJO2 pojo : newList) {
          oldList.add(Beanutils.copy(new POJO2(), pojo));
      }
}

遍历过程将会将原来的 POJO1 全部新建一遍，这些对象一般情况下全部先进入堆内存的新生代，再经过数次 Young GC 后进入老年代。会造成GC频繁。

我所做过的项目，一般认为一天一到两次 Full GC 为合理值。这样，如果比如预先知道某个时间点有大促，可通过提前触发 GC 等方式避免高峰期爆发 Full GC。Young GC 至少是 5 分钟一次，甚至更久触发认为是正常。这样可以通过控制避过秒杀等场景。

JVM 堆外缓存

堆外缓存的内存回收原理使用的是 Java 的虚引用。这个设计可以避免 JVM 的 GC 问题，但是处理不好可能会造成更严重的后果：整个机器内存被打满，机器可能会挂掉。其实挂掉一台在一般企业的生产环境还好，因为一般都会有容灾的冗余机器。但是更常见的一种情况是机器忙于 swap 内存交换，机器活着但是响应很慢。属于半死不活。这个问题我没在线上遇到过，但是我同事之前在超级大厂的时候遇到过。

有的同学说那我严格算好内存，做好监控。这里面要就要依赖人为的因素来做紧急处理。而人是稳定性中最不可靠的。因为问题通常不发生在人清醒、手里事情很少的时候。而是一种雪上加霜的存在。比如大促时，流量上来了，线程数会增多，每个线程都会申请线程栈资源，系统处理 IO，这时候系统会申请更多的 buffers/cached 内存。

Linux 的 buffers/cached

Linux 系统上运行一下 top 命令或者 free 命令，都能够看到 buffers 和 cached 相关的数据。需要注意的是通常我们看到的监控数据空闲内存百分比，并非是下面显示的 free/total，而是 (free+buffers+cached)/total。