JVM GC

垃圾回收机制

分代回收理论

• 新生代：绝大部分的对象都是朝生夕死
• 老年代：熬过多次垃圾回收的对象就越难回收

GC 分类

• 新生代回收（Minor GC/Young GC）
• 老年代回收（Major GC/Old GC）
  • 只有 CMS 垃圾回收器会有这个单独的回收老年代的行为
  • Major GC 有说指是老年代，有说是做整个堆的收集
• 整堆回收（Full GC）：收集整个 Java 堆和方法区（注意包含方法区）

STW (Stop The World)

进行垃圾回收时，必须暂停所有的工作线程，直到它回收结束，这个暂停称之为 STW，JVM 开发团队一直努力消除或降低 STW 的时间。

垃圾回收算法

新生代

复制算法（Copying）- 1:1

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。
但是要注意：内存移动是必须实打实的移动（复制），所以对应的引用(直接指针)需要调整。

复制回收算法适合于新生代，因为大部分对象朝生夕死，那么复制过去的对象比较少，效率自然就高，另外一半的一次性清理是很快的。

复制算法 - Appel 式回收 - 8:1:1

一种更加优化的复制回收分代策略：具体做法是分配一块较大的Eden 区和两块较小的Survivor 空间（你可以叫做From 或者To，也可以叫做 Survivor1 和 Survivor2）

专门研究表明，新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。

HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有10%的内存会被“浪费”。当然，98% 的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）

老年代

标记-清除算法（Mark-Sweep）

算法分为**“标记”和“清除”两个阶段：首先扫描所有对象标记出需要回收的对象，在标记完成后扫描回收所有被标记的对象，所以需要扫描两遍**。回收效率略低，如果大部分对象是朝生夕死，那么回收效率降低，因为需要大量标记对象和回收对象，对比复制回收效率要低。

它的主要问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾回收动作。回收的时候如果需要回收的对象越多，需要做的标记和清除的工作越多，所以标记清除算法适用于老年代。

标记-整理算法（Mark-Compact）

首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记整理算法虽然没有内存碎片，但是效率偏低。

我们看到标记整理与标记清除算法的区别主要在于对象的移动。对象移动不单单会加重系统负担，同时需要全程暂停用户线程才能进行，同时所有引用对象的地方都需要更新（直接指针需要调整）。

三色标记

三色标记最大的好处是可以异步执行，可以以极少的中断时间或者没有中断来进行整个 GC。

三色

• 黑色：根对象，或者该对象与它的子对象都被扫描过
• 灰色：本身被扫描，但是还没扫描完该对象的子对象
• 白色：未被扫描对