公司内接手的老项目近段时间遇到了内存瓶颈，新发版 GC 日志刷个不停，且集中在 YGC，显然有不自然的内存分配，看来内存优化是绕不过了。
在 Java 技术栈内，对内存的分析优化主要集中在堆中，往往需要先使用一些内存分析工具导出堆的一份快照，然后查看是哪些对象在浪费空间，它们可能是非常大的、非常短命的。
除了 JMM，对宿主机的内存管理原理也是有必要掌握的，这样能从底层的角度来进行解释 JMM 的原理，在针对 JMM 进行调参的时候也能更有把握（和运维撕的时候也更不容易被忽悠），鉴于现在的生产环境绝大多数都是 Linux，因此我也会对 Linux 的虚拟内存管理机制作一个简单分析。
LoadingCache 是 Guava 提供的一个本地缓存组件，但是我对它是又爱又恨，一方面因为 LoadingCache 比较完善，免去很多应用层缓存的细节问题（如何写出 GC 友好的缓存？），而另一方面如果对 LoadingCache 了解不够深入又容易出现奇奇怪怪的问题。下面就来描述一下之前碰到过的两个 LoadingCache 的坑，首先给出最简单的缓存配置：
1 | LoadingCache<String, Object> cache = CacheBuilder.newBuilder() |
所以更合理的配置方式应该是下面这样的：
1 | LoadingCache<String, Object> cache = CacheBuilder.newBuilder() |
所以，当我们在使用缓存时，一般是事先考虑：
如果是一些要求不高的内部信息管理系统，这些属性不需要太关注，但是如果是对并发量有一定要求的系统，对自己所使用的工具知根知底是最低的要求。
本地缓存的英文是 Local Cache，Cache、Buffer、Pool 是经常出现但又容易混淆的一组概念，它们都能存取数据，但是有本质上的区别：
⽆法保证⼀致性，解决办法是：
现在基本没有对外应用会是单机部署的，本地缓存是将数据保存到实例本身的内存中，所以一致性问题就是：我们怎么保证同一时间从每台实例上获取到的数据都是相同的？
分层架构设计，有⼀条准则：站点层、服务层要做到⽆数据、⽆状态，这样才能任意的加节点⽔平扩展，数据和状态尽量存储到后端的数据存储服务，例如数据库服务或者缓存服务。
可以看到，站点与服务的进程内缓存，实际上违背了分层架构设计的⽆状态准则，故一般情况下并不推荐使用。
在分布式缓存存在的情况下，一般本地缓存都是不必要的，一方面本地缓存会占用大量的堆空间，容易引起频繁的 GC；另一方面，因为是在局域网内，所以访问分布式缓存的网络开销不会太大。
那么，什么时候可以使⽤进程内缓存？以下情况，可以考虑使用进程内缓存，并且应该注意对过期策略、并发安全等的定义。
当然此时也可以把数据加载到 redis / memcache 等缓存中间件，进程外缓存同样能解决这个问题。
后端开发基本都是完美主义者（粗心导致留下 Bug 可是会被产品、测试鄙视的），但是完美主义也有一个缺点——容易过早优化。
比如，项目早期使用者不多、订单只有 10W～100W 的量级，但是开发刚上来在对行业知识、产品使用场景都没有深刻理解的情况下，直接决定对 id 散列来进行分表，这个对我们来说当然是无可厚非的，但是随着业务扩大、订单量增加到 100W～1000W，发现线上数据库中近期的订单被使用得更多（即热数据）、而老订单一般不被问津，所以原来那种新老混杂的分表就不合适了，但是现在再重构成按时间分表的方式就费事了。因此，更好的方式是刚开始仅用单表存就足够了，之后时刻关注线上使用的反馈，即时地进行优化。
Java 中除了基本类型外所有对象都是通过引用来使用的，引用分为强引用、软引用、弱引用和虚引用。
对于一般的缓存场景来说，软引用是更好的选择，因为软引用可以避免内存用完而 GC 又回收不了内存进而导致的服务宕机，又不会像弱引用那样每次 GC 都会被回收掉、连带导致缓存被击穿。
一般调用 RPC 接口都会有重试逻辑，最简单的重试可以用一个局部变量记录失败次数：
1 | int failedCount = 0; |
如果不是需要实时响应的功能，可以用一个队列缓存请求，然后用一个线程轮询，因为失败后需要重新丢进队列中等待，这时就不能单纯使用局部变量来保存失败次数了，可以使用一个 Cache<string, AtomicInteger>软引用缓存失败调用记录，成功后再使其失效。这种方式能控制失败重试次数，而且当内存不足时，缓存数据可以被 GC 回收以腾出一些空间。
以 Guava 中的 LoadingCache 为例：
1 | private LoadingCache<String, AtomicInteger> failedCache = |
diff（在不等的情况下才 put 或直接修改已有对象，提高内存利用率，不然每次刷新缓存都要放到年轻代。不能用分离链接法实现，因为老的会引用年轻的(每次 put 到头部不就可以了？)，导致年轻代不能转移到老年代）
如何避免 OOM（弱引用）
缓存淘汰机制
过期策略
缓存一般分为本地缓存和分布式缓存两种。本地缓存指的是将数据存储在本机内存中，操作缓存数据的速度很快，但是缺点也很明显：第一，缓存数据的数量与大小受限于本地内存；第二，如果有多台应用服务器，可能所有应用服务器都要维护一份缓存，这样就占用了很多的内存。
分布式缓存正好解决了这两个问题。首先，数据存储在了另外的机器上，理论上由于可以不断添加缓存机器，所以缓存的数据的数量是无限的；其次，缓存集中设置在远程的缓存服务器上，应用服务器不需要耗费空间来维护缓存。但是，分布式缓存也是有缺点的，比如由于是远程操作，所以操作缓存数据的速度相较于本地缓存慢很多。
当前用得最多的本地缓存是 GoogleGuavache，用得最多的分布式缓存是 Memcached 和 Redis
概念及场景：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能 DB 就挂掉了，要是有人利用不存在的 key 频繁攻击我们的应用，这就是漏洞。
解决方案：有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
总而言之，当通过一个 key 去数据库查询出来的数据结果为 null,缓存系统就不会缓存该数据,每次该 key 查询都会经过数据库层,造成没有必要的 DB 开销。这种情况下，我们可以将该 key 缓存至缓存系统中,value 为一个特殊值(^^,&&…)。
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到 DB，DB 瞬时压力过重雪崩。
key 缓存过期失效而新缓存未到期间,该 key 的查询所有请求都会去查询数据，造成 DB 压力上升，产生不必要的 DB 开销
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
解决方案总结：
一些非正常操作（比如导出 excel 文件、运营偶发性访问）而导致内存中出现很多冷数据
选取合适的缓存算法(LUR-N 算法)。
缓存首次上线,如果网站的访问量很大,所有的请求都经过数据库(如果访问量比较少,可以由用户访问自行缓存)
缓存预热,在系统上线之前,所有的缓存都预先加载完毕(增加一个刷新缓存程序,上线后手动刷新或发布时自动调用刷用)
概念及场景：对于一些设置了过期时间的 key，如果这些 key 可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一 key 缓存，前者则是很多 key。缓存在某个时间点过期的时候，恰好在这个时间点对这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。
1.使用互斥锁(mutex key)
业界比较常用的做法，是使用 mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX 或者 Memcache 的 ADD）去 set 一个 mutex key，当操作返回成功时，再进行 load db 的操作并回设缓存；否则，就重试整个 get 缓存的方法。
SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。在 redis2.6.1 之前版本未实现 setnx 的过期时间，所以这里给出两种版本代码参考：
//2.6.1 前单机版本锁
String get(String key) {
String value = redis.get(key);
if (value == null) {
if (redis.setnx(key_mutex, “1”)) {
// 3 min timeout to avoid mutex holder crash
redis.expire(key_mutex, 3 * 60)
value = db.get(key);
redis.set(key, value);
redis.delete(key_mutex);
} else {
//其他线程休息 50 毫秒后重试
Thread.sleep(50);
get(key);
}
}
}
最新版本代码：
public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置 3min 的超时，防止 del 操作失败的时候，下次缓存过期一直不能 load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { //这个时候代表同时候的其他线程已经 load db 并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试
}
} else {
return value;
}
}
memcache 代码：
if (memcache.get(key) == null) {
// 3 min timeout to avoid mutex holder crash
if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
value = db.get(key);
memcache.set(key, value);
memcache.delete(key_mutex);
} else {
sleep(50);
retry();
}
}
除了使用Redis加锁，zk也是常见的分布式锁实现方案：
1 | try { |
2.”提前”使用互斥锁(mutex key)：
在 value 内部设置 1 个超时值(timeout1), timeout1 比实际的 memcache timeout(timeout2)小。当从 cache 读取到 timeout1 发现它已经过期时候，马上延长 timeout1 并重新设置到 cache。然后再从数据库加载数据并设置到 cache 中。伪代码如下：
v = memcache.get(key);
if (v == null) {
if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
value = db.get(key);
memcache.set(key, value);
memcache.delete(key_mutex);
} else {
sleep(50);
retry();
}
} else {
if (v.timeout <= now()) {
if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
// extend the timeout for other threads
v.timeout += 3 * 60 * 1000;
memcache.set(key, v, KEY_TIMEOUT * 2);
// load the latest value from dbplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplain
v = db.get(key);
v.timeout = KEY_TIMEOUT;
memcache.set(key, value, KEY_TIMEOUT * 2);
memcache.delete(key_mutex);
} else {
sleep(50);
retry();
}
}
}
3.”永远不过期”：
这里的“永远不过期”包含两层意思：
(1) 从 redis 上看，确实没有设置过期时间，这就保证了，不会出现热点 key 过期问题，也就是“物理”不过期。
(2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在 key 对应的 value 里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期
从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。
String get(final String key) {
V v = redis.get(key);
String value = v.getValue();
long timeout = v.getTimeout();
if (v.timeout <= System.currentTimeMillis()) {
// 异步更新后台异常执行
threadPool.execute(new Runnable() {
public void run() {
String keyMutex = “mutex:” + key;
if (redis.setnx(keyMutex, “1”)) {
// 3 min timeout to avoid mutex holder crash
redis.expire(keyMutex, 3 * 60);
String dbValue = db.get(key);
redis.set(key, dbValue);
redis.delete(keyMutex);
}
}
});
}
return value;
}
| 解决方案 | 优点 | 缺点 |
|---|---|---|
| 简单分布式互斥锁（mutex key） | 1. 思路简单；2. 保证一致性 | 1. 代码复杂度增大；2. 存在死锁的风险；3. 存在线程池阻塞的风险 |
| “提前”使用互斥锁 | 1. 保证一致性 | 同上 |
| 不过期(本文) | 1. 异步构建缓存，不会阻塞线程池 | 1. 不保证一致性；2. 代码复杂度增大(每个 value 都要维护一个 timekey)；3. 占用一定的内存空间(每个 value 都要维护一个 timekey)。 |
| 资源隔离组件 hystrix(本文) | 1. hystrix 技术成熟，有效保证后端；2. hystrix 监控强大。 | 1. 部分访问存在降级策略。 |
针对业务系统，永远都是具体情况具体分析，没有最好，只有最合适。
最后，对于缓存系统常见的缓存满了和数据丢失问题，需要根据具体业务分析，通常我们采用 LRU 策略处理溢出，Redis 的 RDB 和 AOF 持久化策略来保证一定情况下的数据安全。
详细描述 TODO：
命中率 = 缓存读取次数 / (缓存读取次数 + 慢速设备读取次数)
本地缓存过期时间比分布式缓存小至少一半，以防止本地缓存太久造成多实例数据不一致。
数据的来源，一般称为记录系统或数据源。
回源即回到源头获取数据，Cache 没有命中时，需要从 SoR 获取数据，即回源。
如果有⼤Value 最好切换到多线程实现的缓存如 MC，或者拆成多个小 Value 由客户端聚合。
频繁访问的热点数据，如果每次都要从缓存服务器获取，可能导致缓存服务器负载过高、或者带宽过⾼。
解决办法是加缓存服务器，或者加本地缓存。
原⼦更新：
写本地缓存后异步更新分布式缓存，尽快返回用户请求，最好不要同步写分布式缓存。
场景：一个商品包含多个属性，其中部分属性如上下架这种可能频繁更新的，最好做维度化并增量更新。
读缓存时划分分区异步批量读：
当 db 中本身就没有该数据时，会产生每次请求都击穿的现象，解决办法是引入一个 nullobj。
db 不不存在时写一个 nullobj 到缓存，下次读到 null 对象 就不去 db 读了。
Cache-Aside 即业务代码围绕着 Cache 写，是由业务代码直接维护缓存。
先从缓存获取数据，如果没有命中，则回源到 SoR 并将源数据放入缓存供下次读取使用。
类似 Write-Through 策略。
读可以⽤⼀致性哈希减少并发。
更新可以⽤Canal 订阅 binlog。
很多 Cache 实现了过期的策略的，这些过期的策略可以实现数据的更新，将旧数据失效化，同时也令⼀定时间没有访问的数据失效。
为了让 Cache-Aside 模式能够⽣效，开发者必须确保过期策略能够正确匹配应用所访问的数据。同时，注意不能让过期时间太短，因为太短的过期时间会令应⽤频繁地从数据仓库中获取数据来添加到 Cache 之中。当然，也不要配置超时的时间太⻓，过⻓的超时时间会让缓存的数据冗余。Cache 的性能是跟其相关的数据的读取周期等信息⾼度相关的。
绝⼤多数的缓存跟数据仓库⽐起来，容量是很有限的，所以，如果可以的话，Cache 会移除数据。
多数的 Cache 会采用 LRU 的策略来移除缓存中的数据，当然，移除的策略也是可以⾃定义的。配置全局的过期属性和缓存的其他属性，可以确保 Cache 消耗的内存资源是高效的。当然，通常不会只配置⼀个全局的过期策略。比如，某些特别昂贵、访问特别频繁而又不常更新的数据，完全可以延长其过期时间。
实现 Cache-Aside 模式并不能保证 Cache 和数据仓库之间的数据⼀致性。因为数据仓库中的数据可能在任何时候被其他程序所修改，⽽这个修改不会及时的反映到 Cache 上，直到下一次 Cache 被刷新为止。如果数据仓库中数据频繁由⾮Cahce 程序更新的话，这种一致性问题会变得更加明显。
Cache 也是可以做到应⽤本身里⾯的。Cache-Aside 模式在⼀些应⽤频繁访问相同的数据的时候尤其有效。然⽽，本地 Cache 都是应⽤私有 的，是属于每个应用中独有的额外的拷⻉。所以这个数据可能很快在不同的应⽤中就不一致了，所以刷新的频率最好更快些以保证⼀致性。在 有些情况下可以使⽤共享的缓存，有的时候也可以使⽤本地 Cache，具体使⽤哪⼀种就需要根据实际的场景来判断了。
由 Cache 委托给 SoR 进⾏真实的读写
读 miss 则由 cache 回源到 SoR(需要防⽌dog-pile effect 即 miss 时只允许⼀个请求回源而不是所有请求都回源)。
由 cache 组件负责写缓存和 SoR(一般是先 SoR 再缓存)
异步(队列+线程池)写 SoR
Copy-On-Read
Copy-On-Write
本地缓存的是引⽤，被擅⾃修改可能引起不可预测的问题
所有参考文献的归档，集中管理，方便随时查阅。
不得不承认本地缓存不比分布式缓存更简单，当我们讨论分布式缓存时，更多的是在讨论如何节省带宽、如何平滑扩容，但在本地缓存的范畴内，我们更多的需要关注所使用语言的内存管理机制、甚至需要向下探索到硬件层面（其实分布式缓存的基础一般也是本地缓存）。
Web 缓存指的是在服务器和客户端之间的缓存，不同于我们上边提到的都是服务器（本地缓存）及服务器之后的缓存（分布式缓存）。
Web 缓存其实不仅仅指浏览器内的缓存，在剖析从客户端发送请求到服务器接收为止的一系列链路之后，可以发现 Web 缓存主要包括浏览器缓存、代理服务器缓存、网关缓存。
测试是发现问题的手段，最好的解决问题方式是避免问题。
限流器可以用于限制打入系统的流量或限制系统的对外请求频率，这种想法有点类似 TCP 中的拥塞控制。
在一次编译 jvm 的过程中，尝试将没用版本的 gcc、g++卸载，但是没想到 apt 非常智能地把无线网卡等一系列东西都给删掉了，启动后连网都上不了了，重装系统又觉得麻烦，结果开始了苦逼的填坑之旅。
熔断是兜底杀手锏之一，在一个远程调用框架中，一个服务接口被调用时，如果出错应该优先采取重试的方案，如果多次超时——表明服务确实不可用之后——才会考虑熔断，以避免“灾害”进一步的扩大。
熔断本身没有特别难的算法，但是需要考虑比较多的细节。
幂等性描述一项操作被执行多次后，不会改变第一次执行产生的副作用。
练手项目，解决项目中的幂等性检查要求，代码地址:point_right: Github - TIdempotent。
有一段时间对 Linux 特别感兴趣（现在也一直拿来当桌面系统），因此利用实验课的机会着手开发了一个小游戏，是一个可以多人联机的贪吃蛇游戏，看起来挺 low 的，但是涉及到了 Linux 课上所学的大部分知识，答辩后也得到了不错的结果。代码不是特别规范，下面强行分享一波。
完整代码