这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
前言
大家好呀，这是我参加青训营伴学笔记创作活动的第 9 天，如存在问题，烦请各位斧正！
其中有一些关键图片超过了最大字符限制，不能上传了，我都使用特殊标记给它标记出来了，如有需要，请联系我。
概述
1）此节不过多讨论算法实现，只重点介绍分代收集理论和几种算法思想及其发展过程。
2）由于引用计数式垃圾收集算法在主流Java虚拟机中未涉及，所以本节所有算法均属于追踪式垃圾收集的范畴。
注：从如何判定对象消亡的角度出发，垃圾收集算法可以划分为“引用计数式垃圾收集”和“追踪式垃圾收集”两大类，
这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。
分代收集理论
概述
当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”的理论进行设计，
（名为理论，实则是一套符合大多数程序运行实际情况的经验法则。）
它建立在两个分代假说之上：
1）弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。
2）强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消亡。
设计原则
这两个假说 奠定了多款常用的垃圾收集器的一致的设计原则：
（设计者一般至少会把Java堆划分为新生代和老年代两个区域。）
1）收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。
2）将朝生夕灭和难以消灭的对象集中到不同区域，而不是仅靠标记这些对象来区分。 这更能 同时兼顾垃圾收集的时间开销 和 内存的空间有效利用。
3）针对难以消灭对象的区域，进行的垃圾回收频率也可以相对少一些。
4）划分出区域后才能只回收部分区域，因而才有了“Major GC”“Full GC”这样的回收类型的划分；
（1）部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为：
新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
（2）老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。（实际上除了CMS收集器，其他都不存在只针对老年代的收集）
（请注意“Major GC”的说法有些混淆，有时候要按上下文区分到底是指老年代收集还是整堆收集。）
（2）混合收集（M ixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。
（3）整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。
5）也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法：
如“标记-复制算法”“标记-清除算法”“标记-整理算法”等针对性的垃圾收集算法。
部分问题的解决
分代收集中 对象之间存在的跨代引用 解决：
1）假如只针对新生代垃圾回收，但新生代引用老年代怎么办？在固定的GC Roots之外，再额外遍历整个老年代？这无疑会为内存回收带来很大的性能负担。
2）为了解决这个问题，就需要对分代收集理论添加第三条经验法则：
跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。
（这其实是可根据前两条假说逻辑推理得出的隐含推论：存在互相引用关系的两个对象，是应该倾向于同时生存或者同时消亡的。）
3）依据这条假说，我们就不应再为了少量的跨代引用去扫描整个老年代，也不必费内存去记录每个对象是否跨代引用了，
只需在新生代上建立一个全局的数据结构（该结构被称为“记忆集”，Remembered Set），
这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。
此后当发生M inor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GCRoots进行扫描。
4）虽然这种方法需要在对象改变引用关系（如将自己或者某个属性赋值）时维护记录数据的正确性，会增加一些运行时的开销，
但比起收集时扫描整个老年代来说仍然是划算的。
标记-清除算法
最早出现也是最基础的垃圾收集算法是 "标记-清除" 算法，1960年由Lisp之父提出。
算法分为“标记”和“清除”两个阶段：
1）首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，
也可以反过来，标记存活的对象，统一回收所有未被标记的对象。（标记就是判定对象是否为垃圾的过程）
2）之所以说它是最基础的收集算法，是因为后续的收集算法大多都是以标记-清除算法为基础，对其缺点进行改进而得到的。
3）它的主要缺点有两个：
（1）执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，
这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；
（2）内存空间的碎片化问题：标记、清除之后会产生大量不连续的内存碎片，
空间碎片太多时可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记-复制算法 （简称为复制算法）
1）解决标记-清除算法面对大量可回收对象时执行效率低的问题。
2）1969年的“半区复制”（Semispace Copying）垃圾收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。
（1）实现逻辑：当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，
但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，
而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。
（2）这样实现简单，运行高效，不过其缺陷也显而易见，这种复制回收算法的代价是将可用内存缩小为了原来的一半，空间浪费未免太多了一点。
3）现在的商用Java虚拟机大多都优先采用了这种收集算法去回收新生代：
新生代中的对象有98%熬不过第一轮收集，因此并不需要按照1∶1的比例来划分新生代的内存空间。
4）"Appel式回收"（HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。）
（1）Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。
（2）发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。
（3）HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1。
（4）Appel式回收还有一个充当罕见情况的“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor GC之后存活的对象时，
就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。
若另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，这些对象便将通过分配担保机制直接进入老年代，这对虚拟机来说就是安全的。
（5）采用这种方式时，假如老年代的阈值是15，
那么Eden块必然都是新创建的对象，Survivor必然都是小于15次回收的对象，Old区必然是回收次数大于等于15的对象。
标记-整理算法
1）上面的标记-复制算法不适合老年代： 它在对象存活率较高时效率将会降低。
更关键的是，若不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对对象100%存活极端情况。
2）所以针对老年代对象的存亡特征，有针对性的 "标记-整理" 算法，其基本步骤：
其中的标记过程仍然与"标记-清除"算法一样，但后续操作不是对可回收对象进行清理，
而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。
3）它的缺点： 它与标记-清除算法的本质差异在于：分别是 移动式/非移动式 的回收算法。
是否移动回收后的存活对象是一项优缺点并存的风险决策：
如果移动存活对象，尤其是在老年代这种每次回收 大量存活的区域，
移动存活对象并更新所有引用将是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行。
4）优点： 不需要复杂的内存分配器和内存访问器来解决空间碎片化的问题。（并且空间碎片化后垃圾收集频率也高了）
5）它们俩各有好坏：在内存访问这个环节上增加了额外的负担，势必会直接影响应用程序的吞吐量(赋值器与收集器效率总和)。
移动对象吞吐量相对大 但有停顿时间，不移动对象则相反。
6）HotSpot虚拟机里面关注吞吐量的ParallelScavenge收集器是基于标记-整理算法的，而关注延迟的CMS收集器则是基于标记-清除算法的。
7）另外，还有一种中和的解决方案，做法是让虚拟机平时多数时间都采用标记-清除算法，暂时容忍内存碎片的存在，
直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记-整理算法收集一次，以获得规整的内存空间。
（前面提到的基于标记-清除算法的CMS收集器面临空间碎片过多时采用的就是这种处理办法。）
