Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”，墙外面的人想进去，墙里面的人却想出来。
判断对象死亡
Java虚拟机中如何判断Java对象死亡，需要被回收的呢？
引用计数算法
给对象添加一个计数器，当被引用，就加1，当失效就减一，当计数器为零的时候就是对象不再引用。这种算法实现简单，判断效率也高。
首先，引用计数算法无法解决「循环引用无法回收」的问题，即两个对象互相引用，所以各对象的计数器的值都是 1，即使这些对象都成了垃圾（无外部引用），GC 也无法将它们回收。当然上面这一点还不是引用计数法最大的弊端，引用计数算法最大的问题在于：计数器值的增减处理非常繁重，譬如对根对象的引用，此外，多个线程之间共享对象时需要对计数器进行原子递增/递减，这本身又带来了一系列新的复杂性和问题，计数器对应用程序的整体运行速度的影响。
案例：Redis 中的对象，就是使用引用计数来判断对象是否应该被回收，在 redisObject 结构体中使用了 refcount 来计数。
可达性分析算法
通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始往下搜索，搜索所有走过的路径称为引用链，当一个对象到GC Roots没有任何引用的时候，则证明该对象不可用。
引用
- 强引用：强引用就是指在程序中普遍存在的，类似
Object obj= new Obj这类引用，只要强引用还在，垃圾回收期永远不会回收被引用的对象。 - 软引用：用来描述还有用但并非必需的对象。在系统将要发生内存溢出之前，对这些对象进行二次回收。
- 弱引用：用来描述非必需的对象，但是比软引用强度更弱，被弱引用关联的对象只能存活到下一次垃圾回收之前。
- 虚引用：虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响；也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到个系统通知。
引用队列（ReferenceQueue）
引用队列 ReferenceQueue 是用来配合引用工作的，没有ReferenceQueue一样可以运行。创建引用的时候可以指定关联的队列，当GC释放对象内存的时候，会将引用加入到引用队列，这相当于是一种通知机制。当关联的引用队列中有数据的时候，意味着引用指向的堆内存中的对象被回收。通过这种方式，JVM允许我们在对象被销毁后，做一些我们自己想做的事情。JVM提供了一个ReferenceHandler线程，将引用加入到注册的引用队列中。
生存还是死亡
即使可达性算法中不可达的对象，也并发是”非死不可“，会暂时处于”缓刑“状态，真要宣告一个对象死亡，至少需要经历两次标记过程：如果对象在进行可达性分析后没有和 GC Roots 相连接的引用链，那它会被第一次标记并进行一次筛选，筛选条件是此对象是否有必要执行finalize()方法。
垃圾收集算法
标记-清除算法
首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，它的标记过程其实在前面讲述对象标记判定时已经介绍过了。这是基础算法，别的回收算法都是在这基础上改进的。
缺点：
- 效率不高
- 会产生大量不连续的内存碎片
标记-复制算法
复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这块的内存用完了，就将还存活着的对象复制到另外块上面，然后再把已使用过的内存空间一次清理掉。
缺点：
- 内存的使用率不高，使用中浪费了一半的内存
标记-整理算法
根据老年代的特点，有人提出了另外一种“标记-整理”算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
当前主流的垃圾收集采用的都是”分代收集算法“，新生代使用复制算法，老年代使用标记-整理/清除算法。
根据对象存活周期将内存划分为新生代和老年代。在新生代中，每次垃圾收集都发现大批对象死去，只有少量存活，就选用复制算法；老年代因为对象存活率高、没有额外空间进行分配担保，使用标记-整理/清除算法。
垃圾收集器
Serial收集器
是一个单线程收集器，它进行垃圾收集时，必须暂停其他所有的工作现场，直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。
ParNew收集器
ParNew收集器是Serial收集器的多线程版本。
新生代采用复制算法，老年代采用标记-整理算法。
Parallel Scavenge收集器
Parallel Scavenge 收集器类似于ParNew 收集器。Parallel Scavenge收集器是一个新时代收集器。使用复制算法，并行的多线程收集器。它的吞吐量非常不错。
新生代采用复制算法，老年代采用标记-整理算法。
Serial Old收集器
Serial Old收集器是Serial收集器的老年代版本，使用标记-整理算法。
Parallel Old收集器
是Parallel Scavenge收集器老年代的收集器，使用多线程和标记-整理算法。
CMS收集器
CMS( Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用需求。
CMS收集器使用标记-清除算法。
运作流程：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
1、初始标记只是标记一下 GC Roots 能直接关联到对象，速度很快；
2、并发标记是对 GC Roots Tracing 的过程，从 GC Roots 的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但不需要停顿用户线程；
3、重新标记是为了修正并发标记期间，因用户程序继续运行而导致标记产生变换的一部分，这个阶段的停顿时间一般比初始标记阶段长；
4、并发清除阶段，清除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发；
5、整个 GC 过程中消耗最长的是并发标记和并发清除过程，但是这两个阶段的垃圾回收可以和用户现场一起并发执行。
初始标记和重新标记，需要STW。总体上说，CMS 收集器的内存回收过程式和用户现场一起执行的。
G1收集器
G1 ( garbage-first)收集器是当今收集器技术发展的最前沿成果之一。
G1 将 Java 堆内存分割成若干相同大小的区域，即 region，包括 Eden、Survivor、Old、Humongous 四种类型。其中 Humongous 是特殊的 Old 类型，专门放置大型对象。这样的划分方式意味着不需要一个连续的内存空间管理对象。G1 将空间分为多个区域，优先回收垃圾最多的区域。G1 从整体来看是基于”标记-整理“算法实现的收集器，但从局部(两个 Region 之间)上看又是基于”标记-复制“算法实现的，不过无论如何，这两种算法都不会产生大量的空间碎片。G1 的一大优势在于可预测停顿时间，能尽可能快速地在指定时间内完成垃圾回收任务。
G1 收集器的运作步骤：
- 初始标记：仅仅只是标记一下 GC Roots 能够关联到的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的 Region 中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借助进行 Minor GC (新生代收集，指目标只是新生代的垃圾收集) 的时候同步进行的，所以 G1 收集器在这个阶段实际并没有额外的停顿。
- 并发标记：从 GC Root 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理 SATB (原始快照) 记录下的在并发时有引用变动的对象。
- 最终标记：对用户线程做另一个短暂停顿，用于处理并发阶段结束后仍遗留下来的最后那少量的 SATB 记录。
- 筛选回收：负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期待的停顿时间来制定回收计划，可以自由选择任意多个 Region 构成回收集，然后把决定回收的那一部分 Region 的存活对象复制到空的 Region 中，再清理掉整个旧的 Region 的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多调收集器线程并行完成的。
从上面可以看出， G1 收集器除了并发标记外，其余阶段也是要完全暂停用户线程，换而言之，他并非纯粹地追求低延迟，官方目标：在延迟可控的情况下获得尽可能高的吞吐量。
G1 无论是为了垃圾回收产生的内存占用还是程序运行时的额外执行负载都要比CMS要高。其中内存占用来说，G1 的卡表实现比CMS更加复杂，而且对重每个Region 都必须有一份卡表，这导致G1的记忆集可能占整个堆容量的20%乃至更多的内存空间。
目前在小内存应用上CMS的表现大概率仍然会优于G1，而在大内存上G1则大多能发挥其优势，这个优势的JAVA堆容量平衡点通常在6G ~ 8G之间，之前看到有人说，使用G1的话，最好>=4G。
低延迟垃圾收集器——Shenandoah 收集器
Shenandoah 收集器是RedHat 开源给 OpenJDK 的，被Oracle 官方摒弃在 OracleJDK 外，所以在OracleJDK中是没法见到这款优秀的收集器的。
Shenandoah 也是基于 Region 的堆内存布局，同样有着用于存放大对象的 Humongous Region，默认的回收策略也同样是优先处理回收价值最大的 Region。
Shenandoah 支持并发的整理算法。Shenandoah 是默认不适用分代收集的。
Shenandoah 摒弃了在 G1 中耗费大量内存和计算资源去维护的记忆集，改用名为“连接矩阵”的全局数据结构来记录跨 Region 的引用，降低了处理跨代指针时的记忆集维护消耗，也降低了伪共享问题的发生概率。
- 初始标记：和 G1 一样，首先标记与 GC Roots 直接关联的对象，这个阶段仍是 STW，但停顿时间与堆大小无关，只与 GC Roots 的数量有关。
- 并发标记：与 G1 一样，遍历对象图，标记出全部可达的对象，这个阶段是与用户线程一起并发的，时间长短取决于对重存活对象的数量以及对象图的结构复杂程度。
- 最终标记：与 G1 一样，处理剩余的 STAB 扫描，并在这个阶段统计出回收价值最高的 Region，将这些 Region 构成一组回收集。最终标记阶段会有一小段短暂的停顿。
- 并发清理：这个阶段用于清理那些整个区域内连一个存活对象都没有找到的 Region。
- 并发回收：在这个阶段，Shenandoah 要把回收集里面的存活对象先复制一份到其他未被使用的Region中。Shenandoah 通过读屏障和被称为“Brooks Pointers”的转发指针来解决。并发回收阶段运行的时间长短取决于回收集的大小。
- 初始引用更新：这个阶段需要把堆中所有指向旧对象的引用修正到复制后的新地址。
- 并发引用更新：真正开始进行引用更新操作，这个阶段是和用户线程一起并发的，时间长短取决于内存涉及的引用数量的多少。
- 最终引用更新：解决了堆中的引用更新后，还要修正存在与 GC Roots 中的引用。这个阶段还需要最后一次停顿。
- 并发清理：经过并发回收和引用更新后，整个回收集中所有的 Region 已再无存活对象了。
低延迟垃圾收集器——ZGC 收集器
ZGC 是Oracle公司研发的一款低延迟垃圾收集器。ZGC 是一款基于 Region 内存布局的，(暂时)不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低延迟为首要目的的一款垃圾收集器。
ZGC 的内存布局也是采用 Region 的堆内存布局，不过 ZGC 的 Region 具有动态性——动态创建和销毁，以及动态的区域容量大小。
- 小型Region(Small Region)：容量固定为2MB，用于放置小于256KB的小对象。
- 中型 Region(Medium Region)：容量固定为32MB，用于放置大于等于256KB但小于4MB的对象。
- 大型Region(Large Region)：容量固定，可以动态变化，但必须为2MB的整数倍，用于放置4MB或以上的大对象。
ZGC 的运作过程大致可划分一下四个大阶段。全部四个阶段都是可以并发执行的，仅是两个阶段中间会存在短暂的停顿小阶段。
- 并发标记：并发标记是遍历对象图做可达性分析的阶段，会有一次短暂停顿。ZGC 的标记是在指针上而不是在对象上进行，标记阶段会更新染色指针的Marked 0、Marked 1 标志位。
- 并发预备重分配：这个阶段需要根据特定的查询条件统计得出本次收集过程要清理那些Region，将这些Region组成重分配集。
- 并发重分配：重分配是 ZGC 执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的Region上，并为重分配集的每一个Region维护一个转发表，记录从旧对象到新对象的转向关系。
- 并发重映射：重映射所做的就是修正真个堆中指向重分配集中旧对象的所有引用。由于这一步不是很“迫切”，ZGC 把并发重映射阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成了。
Reference
- 《深入理解Java虚拟机：JVM高级特性与最佳实践（第三版》
- 深入理解虚拟机之Java内存区域
- jvm系列(二):JVM内存结构
阅读
