架构师 01 期，第九周课后作业

作业一：

（至少完成一个）

• 请简述 JVM 垃圾回收原理。

• 设计一个秒杀系统，主要的挑战和问题有哪些？核心的架构方案或者思路有哪些？

在 jvm 中堆空间划分为三个代：年轻代（Young Generation）、年老代（Old Generation）和永久代（Permanent Generation）。

年轻代又分成 3 个部分，一个 eden 区和两个相同的 survior 区。刚开始创建的对象都是放置在 eden 区的。分成这样 3 个部分，主要是为了生命 周期短的对象尽量留在年轻代。当 eden 区申请不到空间的时候，进行 minorGC，把存活的对象拷贝到 survior

1、对象在 Eden 区完成内存分配

2、当 Eden 区满了，再创建对象，会因为申请不到空间，触发 minorGC，进行 young(eden+1survivor)区的垃圾回收

3、minorGC 时，Eden 不能被回收的对象被放入到空的 survivor（Eden 肯定会被清空），另一个 survivor 里不能被 GC 回收的对象也会被放入这个 survivor，始终保证一个 survivor 是空的

4、当做第 3 步的时候，如果发现 survivor 满了，则这些对象被 copy 到 old 区，或者 survivor 并没有满，但是有些对象已经足够 Old，也被放入 Old 区 XX:MaxTenuringThreshold

5、当 Old 区被放满的之后，进行 fullGC

判断一个对象是否可回收

1. 给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收。两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。正因为循环引用的存在，因此 Java 虚拟机不适用引用计数算法。

2. 可达性分析算法

通过 GC Roots 作为起始点进行搜索，能够到达到的对象都是存活的，不可达的对象可被回收。Java 虚拟机使用该算法来判断对象是否可被回收，在 Java 中 GC Roots 一般包含以下内容：

• 虚拟机栈中引用的对象

• 本地方法栈中引用的对象

• 方法区中类静态属性引用的对象

• 方法区中的常量引用的对象

垃圾收集算法

1. 标记 - 清除

将需要回收的对象进行标记，然后清理掉被标记的对象。

不足：

• 标记和清除过程效率都不高；

• 会产生大量不连续的内存碎片，导致无法给大对象分配内存。

1. 标记 - 整理

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

1. 复制

将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。主要不足是只使用了内存的一半。

垃圾回收器一直在发展，一共经历了四个阶段：

1. Serial（串行）收集器

2. Parallel（并行）收集器

3. CMS（并发）收集器

4. G1 收集器

G1 也有两种收集模式：

• Young GC： 当 Eden 区达到一定阈值时触发；会将 Eden 和 Survivor 清理，并复制到 Old 区以及一部分 Survivor 区。

• MixedGC：Old 区也达到一定阈值时，回收所有 Eden 区、Survivor 区，以及部分 Old 区的内存。

内存分配与回收策略

对象的内存分配，也就是在堆上分配。主要分配在新生代的 Eden 区上，少数情况下也可能直接分配在老年代中。

1. Minor GC 和 Full GC

• Minor GC：发生在新生代上，因为新生代对象存活时间很短，因此 Minor GC 会频繁执行，执行的速度一般也会比较快。

• Full GC：发生在老年代上，老年代对象和新生代的相反，其存活时间长，因此 Full GC 很少执行，而且执行速度会比 Minor GC 慢很多。

2. 内存分配策略

（一）对象优先在 Eden 分配

大多数情况下，对象在新生代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC。

（二）大对象直接进入老年代

大对象是指需要连续内存空间的对象，最典型的大对象是那种很长的字符串以及数组。

经常出现大对象会提前触发垃圾收集以获取足够的连续空间分配给大对象。

-XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制。

（三）长期存活的对象进入老年代

为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中。

-XX:MaxTenuringThreshold 用来定义年龄的阈值。

（四）动态对象年龄判定

虚拟机并不是永远地要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 区中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。

（五）空间分配担保

在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的；如果不成立的话虚拟机会查看 HandlePromotionFailure 设置值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者 HandlePromotionFailure 设置不允许冒险，那这时也要改为进行一次 Full GC。

3. Full GC 的触发条件

对于 Minor GC，其触发条件非常简单，当 Eden 区空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：

（一）调用 System.gc()

此方法的调用是建议虚拟机进行 Full GC，虽然只是建议而非一定，但很多情况下它会触发 Full GC，从而增加 Full GC 的频率，也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存。可通过 -XX:DisableExplicitGC 来禁止 RMI 调用 System.gc()。

（二）老年代空间不足

老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等，当执行 Full GC 后空间仍然不足，则抛出 Java.lang.OutOfMemoryError。为避免以上原因引起的 Full GC，调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间以及不要创建过大的对象及数组。

（三）空间分配担保失败

使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果出现了 HandlePromotionFailure 担保失败，则会触发 Full GC。

（四）JDK 1.7 及以前的永久代空间不足

在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError，为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。

（五）Concurrent Mode Failure

执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（有时候“空间不足”是 CMS GC 时当前的浮动垃圾过多导致暂时性的空间不足触发 Full GC），便会报 Concurrent Mode Failure 错误，并触发 Full GC。