Java 会对内存进行自动分配与回收管理，使上层业务更加安全，方便地使用内存实现程序逻辑。在不同的JVM 实现及不同的回收机制中，堆内存的划分方式是不-样的。这里简要介绍垃圾回收(Garbage Collection，GC)。垃圾回收的主要目的清除不再使用的对象，自动释放内存。
GC 是如何判断对象是否可以被回收的呢?为了判断对象是否存活，JVM 引入了GC Roots。如果一个对象与 GC Roots 之间没有直接或间接的引用关系，比如某个失去任何引用的对象，或者两个互相环岛状循环引用的对象等，判决这些对象“死缓”,是可以被回收的。什么对象可以作为 GC Roots 呢? 比如: 类静态属性中引用的对象、常量引用的对象、虚拟机栈中引用的对象、本地方法栈中引用的对象等。
有了判断对象是否存活的标准后，再了解一下垃圾回收的相关算法。最基础的为“标记-清除算法”，该算法会从每个 GC Roots 出发，依次标记有引用关系的对象，最后将没有被标记的对象清除。但是这种算法会带来大量的空间碎片，导致需要分配个较大连续空间时容易触发 FGC。为了解决这个问题，又提出了“标记 - 整理算法”，该算法类似计算机的磁盘整理，首先会从 GC Roots 出发标记存活的对象，然后将存活对象整理到内存空间的一端，形成连续的已使用空间，最后把已使用空间之外的部分全部清理掉，这样就不会产生空间碎片的问题。“Mark-Copy”算法，为了能够并行地标记和整理将空间分为两块，每次只激活其中一块，垃圾回收时只需把存活的对象复制到另一块未激活空间上，将未激活空间标记为已激活，将已激活空间标记为未激活，然后清除原空间中的原对象。堆内存空间分为较大的 Eden 和两块较小的Survivor，每次只使用 Eden 和 Survivor 区的一块。这种情形下的“Mark-Copy”减少了内存空间的浪费。“Mark-Copy”现作为主流的YGC算法进行新生代的垃圾回收。
垃圾回收器(Garbage Collector)是实现垃圾回收算法并应用在JVM 环境中的内存管理模块。当前实现的垃圾回收器有数十种，本文章只介绍 Serial、CMS、G1三种。
Serial 回收器是一个主要应用于 YGC 的垃圾回收器，采用串行单线程的方式完成GC任务，其中“Stop The World”简称STW，即垃圾回收的某个阶段会暂停整个应用程序的执行。FGC 的时间相对较长，频繁 FGC 会严重影响应用程序的性能。主要流程如图所示。
CMS 回收器( Concurrent Mark Sweep Collector)是回收停顿时间比较短、目前比较常用的垃圾回收器。它通过初始标记(Initial Mark)、并发标记(Concurrent Mark )、重新标记 ( Remark )、并发清除(Concurrent Sweep)四个步完成垃圾收工作。第1、3步的初始标记和重新标记阶段依然会引发 STW，而第 2、4步的并发标记和并发清除两个阶段可以和应用程序并发执行，也是比较耗时的操作，但并不影响应用程序的正常执行。由于 CMS 采用的是“标记 - 清除算法”，因此产生大的空间碎片。为了解决这个问题，CMS 可以通过配置-XX:+UseCMSCompactAtFulCollection=n参数，强制JVM 在FGC 完成后对老年代进行压缩，执行一次空间碎片整理但是空间碎片整理阶段也会引发 STW。为了减少 STW 次数，CMS 还可以通过配置XX:+CMSFullGCsBeforeCompaction=n 参数，在执行了次 FGC后，JVM再在老年代执行空间碎片整理。
Hotspot 在JDK7中推出了新一代G1( Garbage-First Garbage Collector )垃圾回通过-XX:+UseG1GC 参数启用。和 CMS 相比，G1 具备压缩功能，能免碎片问题G1的暂停时间更加可控。性能总体还是非常不错的，简要结构如图所示。
G1将Java 堆空间分割成了若干相同大小的区域，即region，包括Eden、Survivor、Old、Humongous 四种类型。其中，Humongous 是特殊的 Old 类型，专放置大型对象。这样的划分方式意味着不需要一个连续的内存空间管理对象。G1将空间分为多个区域，优先回收垃圾最多的区域。G1采用的是“Mark-Copy”，有非好的空间整合能力,不会产生大量的空间碎片。G1的一大优势在于可预测的停顿时间能够尽可能快地在指定时间内完成垃圾回收任务。在JDK11 中，已经将 G1设为默认垃圾回收器，通过jstat命令可以查看垃圾回收情况，如图所示，在YGC时SO/S1并不会交换。
S0/S1的功能由G1中的 Survivor region 来承载。通过GC 日志可以观察到完整的垃圾回收过程如下，其中就有 Survivor regions 的区域从0个到1个。
[0.530s]linfo llge,start ] GC(O) Pause Initial Mark (G1 Humongous Allocation)
[0.530s][info][gc,task]GC(0) Using 4 workers of 4 for evacuation
[0.535s][info lgc,heap]GC(0) Eden regions:2->0(152)
[0.535s][info ][gc,heap]GC(0) Survivor regions:0->1(2)
[0.535s][info ][gc,heap]GC(0) Old regions:0->0
[0.535s][info ][gc,heap]GC(0) Humongous regions: 115->39
[0.535s][info llgc,metaspace ]GC(0) Metaspace: 6001K->6001K(1056768K)
红色标识的为 G1中的四种region，都处于Heap中。G1执行时使用4个worker 并发执行，在初始标记时，还是会触发STW，如第一步所示的 Pause。G1 的Concurrent Marking 分为五个主要步聚
第一步，Initial Mark，其实就是 YoungGC。该阶段会引起STW，它会标记GC Roots 直接可达的存活对象。GC 日志如下:[GC pause(G1 Evacuation Pause)(young)(initial-mark),0.0008405 secs]。
第二步，Root Region Scan，即根区域扫描。该阶段不会引起STW，它会并发地从上一阶段标记的存活区域中扫描被引用的老年代对象。GC日志如下:[GC concurrent-root-region-scan-start][GC concurrent-root-region-scan-end,0.0000050 secs]。
第三步，Concurrent Mark，即并发标记。该阶段从堆中标记存活的对象，与CMS类似。GC日志如下[GC concurrent-mark-startGC concurrent-mark-end,0.0169973secs]。
第四步，Remark，即重新标记。该阶段会引起STW，与CMS 类似。它会完成最终的标记处理。GC日志如下:[GC remark[Finalize Marking,0.0001883 secs][GC-ref-proc,0.0000471 secs] [Unloading,0.0008435 secs],0.0055849 secs][Times: user=0.03sys=0.01,real=0.00 secs] 。
第五步，Cleanup，主要为接下来的 Mixed GC 做准备。该阶段会统计所有堆区域中的存活对象，并将待回收区域按回收价值排序，优先回收垃圾最多的区域GC日志如下:[GC cleanup 2308M->2308M(3929M),0.0030328 secs][Times: user-0.01 sys=0.00,real=0.00 secs]。
在JDK11 版本中，引入试验性质的新 GC 算法 ZGC，它是一个可伸缩的低延垃圾收集器，宣称暂停时间不超过10毫秒。ZGC会因为GC Root增大而增加暂停时间比如很多 Thread。Thread 的堆栈很深，但是与堆大小以及 Live Data Size 无关。ZG处理堆范围从几百 MB 到几TB。ZGC 的目标是吞吐量降低不超过 15%，与G1一样在ZGC中将堆内存分成大量的内存区域，即 ZPage，区别是 ZGC中的区域大小是不相同的，有小型、中型和大型之分。在小型 page 中分配小对象，最大为 256KB;在中型 page 中分配中等大小的对象，最大为4MB;在大型 page中分配大于4MB 的对象ZGC 包括十个阶段，最主要的两个阶段是 mark 和relocate，GC 不断从标记阶段开始循环，递归所有可达对象，标记结束时可以知道哪些对象可以被回收。ZGC 将记结果存储在每个page的 live bitmap 中。在标记过程中，应用线程中的load barrie将暂时未标记的引用对象压入缓冲区。一旦缓冲区满，GC 线程会递归遍历此缓冲区中所有可达对象。标记结束后，ZGC 需要迁移relocate 集合中所有的对象。relocate集合是一组 page 集合，根据某些标准，系统决定是否需要迁移它们。ZGC为每个relocate集合的页面分配了forwarding table。它是一个哈希映射(如果对象已经被迁)它存储一个对象被移动后的新地址。为了实现 ZGC 的目标，增加了两种方式:着色指针和读屏障。前者使用简洁的多重映射技巧可以处理更多的内存。所谓试验性质是指该策略在JDK11中只会支持 Linux 系统，其他平台暂不支持，并且在生产环境中还需要考虑如下问题:第一，如何支持 class unloading，这是一个功能性缺失;第二,compressed ref 和ZGC 是冲突的，开ZGC，一定不能有 compressed ref; 第三，解决single generation 问题，因为应用的分配速率过高的话，GC 有可能跟不上，这可能是潜在问题。
