垃圾回收

标记-清除

该算法分为“标记”和“清除”阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会带来两个明显的问题：

1. 效率问题
2. 空间问题（标记清除后会产生大量不连续的碎片）

复制

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

标记-整理

根据老年代的特点提出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

分代收集

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

HotSpot的算法

可达性分析会导致gc停顿，因为必须保证确保一致性，也就是冻结在某个时间点，所以我们必须要停顿。

但是停顿太久的代价我们是不能承受的。

在hotspot虚拟机中，采用OopMap结构记录哪些地方存着引用的。

但是，也不可能为每一个指令设置OopMap，只有在“安全点”才记录，gc也是在安全点才暂停。

安全点的选定不能太少：导致gc等待时间长

太多：导致过分增大负荷。

但是还不能解决问题：我们确实保证了运行时，隔一段时间就能进入安全点，但是不运行的时候呢？（程序未抢到cpu很久）

安全区：指这一段代码中，引用关系绝对不会发生变化。在这个区域中任意地方开始gc都是安全的。