简介
GC 是垃圾回收器的简称，全称是Garbage Collection。
Stop The World 在这里非常重要。当 Stop The World 发生时，除GC所需的线程外，所有的线程都进入等待状态，直到 GC 任务完成。每一代的Java垃圾回收器，都把缩减 Stop The World 停顿时间作为很重要的目标。
JVM GC只回收堆区和方法区内的基本类型数据和对象。
是否允许被回收
引用计数法
在对象里添加一个被引用的计数器，每当有地方引用了它，计数器就加1，引用失效时，计数器就减1。
在触发回收内存的时候，遍历所有对象，把计数器值等于0的找出来，释放掉即可。
但是它有个问题，无法回收互相引用的对象！
所以，市面上主流的Java虚拟机都没有使用这个算法，而是使用可达性分析法做为判断对象是否存活的算法。
可达性分析法（根搜索算法）
其实不止是Java，C# 也是使用可达性分析算法来判断对象是否存活的，这个算法也可以称之为根搜索算法。
基本原理是通过一系列可被作为 GC Roots 的根对象来作为起始节点，从这些节点开始，根据引用关系向下搜索，搜索过程的就是一条引用链（Reference Chain），没有在这个链条上面的对象，也就是根节点通过引用链不可达到这个对象时，就认为这个对象是可以被回收的。
哪些对象可以作为根节点呢？
在虚拟机栈帧中引用的对象，例如线程调用方法时，使用或产生的参数、局部变量、临时变量等。
在方法区中，类的引用类型静态变量或常量。
在本地方法栈中的JNI引用的对象，
在JVM内部的对象，例如基本数据类型的Class对象，一些常驻的异常对象（NullPointExcepiton），系统类加载器等。
所有synchronized同步锁的持有对象。
反映JVM内部情况的JMXBean、JVMTI注册的回调、本地代码缓存等。
……
JVM GC什么时候执行
当程序创建一个新的对象或者基本类型的数据，内存空间不足时，会触发GC的执行。
分代回收机制
大多数的商业虚拟机，都采用分代回收的理论来设计垃圾收集器。既然绝大多数对象都熬不过几次垃圾回收，而熬过多次回收的对象又很难消亡，那么可以根据年龄把它们划分到不同的区域，例如新生代区域和老年代区域，然后分而治之。
各区域触发垃圾回收的类型与解释：
- Minor GC：只回收新生代区域。
- Major GC：只回收老年代区域。只有CMS实现了Major GC，所以在老年代里，触发GC，除了CMS和G1之外的其他收集器，大多数触发的其实是 Full GC
- Full GC：回收整个堆区和方法区
- Mixed GC：回收整个新生代和部分老年代。G1收集器实现了这个类型。
新生代（Young generation）
绝大多数新创建的对象都会被分配到这里，这个区域触发的垃圾回收称之为：Minor GC 。
默认情况下，新生代（Young generation）、老年代（Old generation）所占空间比例为 1 : 2 。
默认情况下，新生代空间的分配：Eden : Fron : To = 8 : 1 : 1
新生代GC收集的执行顺序如下
- 绝大多数新创建的对象会存放在Eden空间。
- 在Eden空间执行第 1 次GC（Minor GC）之后，存活的对象被移动到其中一个幸存者空间（Survivor）。
- 此后每次 Minor GC，都会将 Eden 和 使用中的Survivor 区域中存活的对象，一次性复制到另一块空闲中的Survivor区，然后直接清理 Eden 和 使用过的那块Survivor 空间。
- 从以上空间分配我们知道，Survivor区内存占比很小，当空闲中的Survivor空间不够存放活下来的对象时，这些对象会通过分配担保机制直接进入老年代。
- 在以上步骤中重复N次（N = MaxTenuringThreshold（年龄阀值设定，默认15））依然存活的对象，就会被移动到老年代。
新创建的对象，是保存在Eden空间的。那些经历多次GC依然存活的对象会经由Survivor空间转存到老年代空间（Old generation）。
老年代（Old generation）
对象在新生代周期中存活了下来的，会被拷贝到这里。通常情况下这个区域分配的空间要比新生代多。正是由于对象经历的GC次数越多越难回收，加上相对大的空间，发生在老年代的GC次数要比新生代少得多。这个区域触发的垃圾回收称之为：Major GC 或者 Full GC
为什么老年代的回收耗时，比新生代更长
- 老年代内存占比更大，所以理论上回收的时间也更长
- 老年代使用的是标记-整理算法，清理完成内存后，还得把存活的对象重新排序整理成连续的空间，成本更高
方法区（Method area）
这个区域主要回收废弃的常量和类型，例如常量池里不会再被使用的各种符号引用等等。类型信息的回收相对来说就比较严苛了，必须符合以下3个条件才会被回收：
- 所有实例被回收
- 加载该类的ClassLoader 被回收
- Class 对象无法通过任何途径访问（包括反射）
跨代引用的问题
新生代中的对象很有可能会被老年代里的对象所引用，当新生代触发GC的时候，只搜索新生代的区域明显是不够的，还得搜索老年代的对象是否引用了新生代中非 GC Roots 引用链上的对象，来确保正确性。但这样做会带来很大的性能开销。为了解决这个问题，Java定义了一种名为记忆集的抽象的数据结构，用于记录存在跨区域引用的对象指针集合。
大多数的虚拟机，都采用一种名为卡表（Card Table）的方式去实现记忆集，卡表由一个数组构成，每一个元素都对应着一块特定大小的内存区域，这块内存区域被称之为卡页（Card Page），每一个卡页，可能会包含N个存在跨区域引用的对象，只要存在跨区域引用的对象，这个卡页就会被标识为1。当GC发生的时候，就不需要扫描整个区域了，只需要把这些被标识为1的卡页加入对应区域的 GC Roots 里一起扫描即可。
总结整个过程
图示
图中大致将各个代说明了一下各个代的关系。
上图中则是大致说明了对象后的生命周期
- 首先是创建并在新生代eden中
- 此时如果发生gc则会判断其大小，如果过大则直接进入老年代，否则就进入s1中
- gc时s1和s2会发生循环往复的复制，其一是用来计算代数，其二是因为这里会经常发生数据调整产生数据碎片导致存储率降低，因此复制调整也是为了减少碎片提高使用率
- 而当s1和s2每次换代的时候，就会计算如果超过了阀值则进入老年代
回收算法讲解
标记 - 清除算法
这个算法和它的名字一样，分两个步骤：标记 和 清除。首先标记出所有存活的对象，再扫描整个空间中未被标记的对象直接回收。
并没有规定标记阶段一定要标记“存活”的对象，也可以标记“可回收”的对象。但是是标记存活的。这样效率高些。
首先，Java使用的是可达性分析算法来判断对象是否存活。
我们假设要标记“可回收”的对象，再进行清除，那么需要三个步骤：
- 1、先通过可达性分析法，通过根对象（GC Roots）顺着引用链先把这些存活对象都标出来
- 2、遍历这个区域所有对象，把没标记存活的对象，打上一个“可回收”的标记
- 3、遍历这个区域所有对象，把标记了“可回收”的对象，释放掉。
但标记的是“存活”的对象，再进行清除，只需要两个步骤即可：
- 1、先通过可达性分析法，通过根对象（GC Roots）顺着引用链先把这些存活对象都标出来
- 2、遍历这个区域所有对象，把没标记存活的对象，直接清理掉即可。
所以，标记“可回收”的对象，会多了一次完全没有必要的遍历。
可以看到在标记后，就会将未标记的清除掉，但是有一个问题，由于回收后没有进行整理的操作，所以会存在内存空间碎片化的问题。
但是反过来想，正是因为没有标记，效率才会高。
标记 - 复制算法
一个80%的Eden空间和两个10%的Survivor空间。
每次分配内存，只使用Eden和其中一块Survivor空间，发生GC回收时，把Eden和其中一块Survivor空间中存活的对象，复制到另一块空闲的Survivor空间，然后直接把Eden和使用过的那块Survivor空间清理掉。
这个在上面的分代回收机制中已说明。
目前主流的使用分代回收机制的Java虚拟机，都是使用标记-复制算法来作为新生代的回收算法。它非常适合用在新生代这种回收率极高的场景，这样的场景下，复制算法浪费的空间几乎可以忽略不计。效率高，且内存不会有碎片化的问题。但对于老年代这种存活率很高的场景，就不适合了。
标记-复制算法还有一个非常重要的知识点，就是分配担保机制。虽然GC新生代里98%的对象都会被回收，但这不是百分之百的几率，极端情况下可能会出现超过10%的对象存活。分配担保机制就是为了保证当出现这种情况时，有其他内存空间来进行兜底。通常这个“担保人”是老年代，当存活的对象超过Survivor空间大小时，这些存活的对象会忽略年龄，直接进入老年代里。
标记 - 整理算法
标记-清除算法会产生内存碎片，不适合哪些需要大量连续内存空间的场景，而标记-整理算法，就是在其基础之上，增加了整理这个操作，去解决这些内存空间碎片化的问题，
和标记-清除算法一样，先标记，但清除之前，会先进行整理，把所有存活的对象往内存空间的左边移动，然后清理掉存活对象边界以外的内存，即完成了清除的操作。标记-整理 算法是在 标记-清除 算法之上，又进行了对象的移动排序整理，因此成本更高，但却解决了内存碎片的问题。
老年代里的对象存活率很高，不适合使用标记-复制的算法。而且老年代存储大对象的概率要比新生代大很多，这些大对象需要连续的内存空间来存储，标记-清除这个算法也不适合。所以大多数的老年代都采用标记-整理来作为这个区域的回收算法。
常用的垃圾回收器
目前应用范围最广的，应该还是JDK8，它默认使用的是 Parallel Scavenge + Parallelo Old 收集器组合。
Serial（-XX:+UseSerialGC）
Serial 是Java虚拟机初代收集器，在JDK1.3之前是Java虚拟机新生代收集器的唯一选择，这是一个单线程工作的收集器。在进行垃圾回收的时候，需要暂停所有的用户线程，直到回收结束。
虽然历史久远，但它依然是HotSpot虚拟机运行在客户端模式下，或者4核4GB以下服务端的默认新生代收集器，这种核心数和内存空间较小的场景下，它单线程的优势就体现出来了，没有线程交互的开销，加上内存空间不大，单次回收耗时几十毫秒，这点停顿时间，完全是可以接受的。
Serial 负责收集新生代区域，它采用标记-复制算法。
Serial Old（-XX:+UseSerialOldGC）
SerialOld 是 Serial 收集器的老年代版本，和 Serial 一样，它也是单线程的收集器。目前主要应用在客户端模式（Client VM）下的HotSpot虚拟机使用。
如果在服务端模式（Server VM）下，它也有两种用途：一个是在JDK5以及之前，和Parallel Scavenge收集器搭配使用，另外一个就是作为CMS收集器在出现并发模式故障（Concurrent Mode Failure） 时作为后备收集器。
SerialOld 负责收集老年代区域，它采用标记-整理算法。
ParNew（-XX:+UseParNewGC）
Serial 收集器单线程的性能明显比较落后了，ParNew 就是 在Serial 收集器的基础之上，实现了它的多线程版本。它可以多条线程同时进行垃圾收集，这也是它和 Serial 收集器的最大的区别，其他的功能性、配置、策略等等的和 Serial 基本一致。
在JDK9之后，Java官方取消了ParNew和除了CMS收集器之外的所有老年代收集器的搭配，而且还取消了 - XX:+UseParNewGC 这个参数。所以JDK9之后，ParNew只能和CMS搭配使用了。
ParNew 负责收集新生代区域，它采用标记-复制算法。
Parallel Scavenge（-XX:+UseParallelGC）
Parallel Scavenge 从外观上看，和 ParNew 很相似，都是新生代的收集器，支持多线程并行回收，也同样是使用标记-复制来作为回收算法。但 Parallel Scavenge 的关注点不一样，它的目标是实现一个可控制吞吐量的垃圾收集器。
吞吐量的计算公式：运行用户代码时间 / (运行用户代码时间 + 运行垃圾收集时间)
Parallel Scavenge 收集器提供了一些参数，给用户按自身需求控制吞吐量：
-XX:MaxGCPauseMillis
控制垃圾收集停顿的最大时间，单位是毫秒，可以设置一个大于0的数值。
不要想着把这个数值设置得很小来提升垃圾收集的速度，这里缩短的停顿时间是以牺牲新生代空间大小换来的，空间小，回收自然就快，停顿时间自然也短，但是空间小，吞吐量自然也会小。所以得综合考虑。-XX:GCTimeRatio
设置垃圾收集时间占比的计算因子，参数范围是0 - 100的整数。它的公式是 1 / (1+GCTimeRatio)
举个栗子：当设置成15，那就是 1 / (1+15) = 0.0625，就是允许最大垃圾收集时间占总时间的6.25%，当设置成99的时候，就是 1 / (1+99) = 0.01，也就是允许最大垃圾收集时间占总时间的1%，依次类推。-XX:+UseAdaptiveSizePolicy
动态调整开关，这个参数和 Parallel Scavenge 收集器无关，但是搭配起来使用是一个很好的选择。
当这个参数被激活，就不需要人工指定新生代的大小、Eden和Survivor区的比例、对象直接进入老年代的大小等等细节参数了，JVM会根据当前运行的情况动态调整，给出最合适的停顿时间和吞吐量。搭配以上两个参数，和把基本的内存数据设置好即可，例如堆的最大占用空间等等。
Parallel Old（-XX:+UseParallelOldGC）
就像 Serial Old 是 Serial 的老年代版本一样，Parallel Old 是 Parallel Scavenge 的老年代版本。
Parallel Old 也支持多线程并行回收的能力，使用标记-整理来作为回收算法。这个收集器是JDK6的时候推出的，和 Parallel Scavenge 搭配，在多CPU核心和大内存的场景下，吞吐性能优秀。
在注重吞吐量和多CPU核心的情况下，都可以优先考虑 Parallel Scavenge + Parallelo Old 收集器，这也是JDK8默认的垃圾收集器组合。
CMS （-XX:+UseConcMarkSweepGC）
CMS（Concurrent Mark Sweep） 是JDK1.4后期推出的GC收集器，它是一款并发低停顿的收集器，对于响应速度有较高要求，对停顿时间忍受度低的应用，非常适合使用CMS作为垃圾收集器。
CMS 负责收集老年代区域，它采用标记-清除算法。
它的运行过程相对于前几个来说会复杂一些，可以分为四个步骤：
- 1、初始标记（CMS initial mark）
- 这个阶段需要 Stop Tow World（暂停暂停所有用户线程），但这个阶段的速度很快，因为只标记和根节点（GC Roots）直接关联的对象。
- 2、并发标记（CMS Concurrent mark）
- 这个阶段不需要 Stop Tow World，在初始标记完成后，并发标记从GC Roots直接关联的对象开始，遍历整个引用链，这个阶段耗时较长，但用户线程可以和GC线程一起并发执行。
- 3、重新标记（CMS remark）
- 这个阶段需要 Stop Tow World，因为并发标记阶段，用户线程和标间线程同时在运行，相当于一边扫地一边丢垃圾，重新标记就是修正用户线程继续运行，导致的变动的那一部分对象。这一阶段的耗时比初始标记长一些，但远没有达到并发标记阶段那么长的时间。这个阶段可以多线程并行标记。
- 4、并发清理（Concurrent sweep）
- 这个阶段不需要 Stop Tow World，执行到这里，说明标记阶段已经完成，此时遍历整个老年代的内存空间，清理掉可回收的对象，由于不需要移动整理存活的对象，这个阶段可以允许用户线程和回收线程并发执行。在清理完成后，会重置CMS收集器的数据结构，等待下一次垃圾回收。
以上4个步骤可以看出，CMS之所以能实现低延迟，是因为它把垃圾搜集分成了几个明确的步骤，在一些耗时较长的阶段实现了用户线程和GC线程并发执行的能力。用两次短暂的 Stop Tow World 来代替了其他收集器一整段长时间的 Stop Tow World。
CMS确实是非常优秀的垃圾收集器，但它也是有缺点的
- 1、内存碎片。由于使用了 标记-清理 算法，回收结束后会产生大量不连续的内存空间，也就是内存碎片。
- 2、GC进行时会降低吞吐量。由于使用了并发处理，很多情况下都是GC线程和应用线程并发执行的，GC线程肯定会占用一部分计算资源，这个期间会降低一部分吞吐量（尽管这样，也比之前几个收集器好很多）。
- 3、浮动垃圾。CMS有两个阶段是可以用户线程和GC线程并发执行的，用户线程的继续执行自然会伴随垃圾的不断产生，这些就是浮动垃圾。这些垃圾只能等下次触发GC的时候才能清除了，也因为这些浮动垃圾的存在，CMS收集器需要留一手，JDK5的时候，在老年代内存空间使用了68%的时候就会触发一次GC，到了JDK6，觉得JDK5的这个设置太保守了，所以调整到了92%。
可以通过-XX:CMSInitiatingOccupancyFraction 调整这个阈值
Garbage First（G1）
G1 是 Garbage First 收集器的简称，它在JDK7的时候立项，JDK8 Update 40的时候才全部完工。这个收集器在JDK9 的时候成为了服务端模式下的默认垃圾收集器。
G1 收集器的设计理念是：实现一个停顿时间可控的低延迟垃圾收集器
G1 依然遵循分代回收的设计理论，但它对堆（Java Heap）内存进行了重新布局，不再是简单的按照新生代、老年代分成两个固定大小的区域了，而是把堆区划分成很多个大小相同的区域（Region），新、老年代也不再固定在某个区域了，每一个Region都可以根据运行情况的需要，扮演Eden、Survivor、老年代区域、或者Humongous区域。
大对象会被存储到Humongous区域，G1大多数情况下会把这个区域当作老年代来看待。如果对象占用空间超过Region的容量，就会存放到N个连续的 Humongous Region 中。
收集器的运行过程可以大致分成四个步骤：
- 初始标记（Initial Marking）- Stop Tow World
- 只标记 GC Roots 能直接关联的对象，还有一些额外的细节操作例如修改TAMS指针的值，保证后续阶段用户程序并发运行的时候，新对象分配在正确的位置。这个阶段需要暂停用户线程，但耗时很短。
- 并发标记（Concurrent Marking）- No Stop Tow World
- 从根节点（GC Root）开始，顺着引用链遍历整个堆，找出存活的对象。这个步骤耗时较长，但用户线程可以和GC线程并发执行。
- 最终标记（Final Marking）- Stop Tow World
- 处理并发标记阶段，用户线程继续运行产生的引用变动，这个阶段需要暂停用户线程，支持并行处理。
- 筛选回收（Live Data Counting and Evacuation）- Stop Tow World
- 根据以上三个阶段标记完成的数据，计算出各个Region的回收价值和成本，再根据用户期望的停顿时间来决定要回收多少个Region。回收使用的是复制算法，把需要回收的这些Region里存活的对象，复制到空闲的Region中，然后清理掉旧Region全部空间。因为需要移动存活的对象，所以不可避免的要暂停用户线程，这个步骤支持多条线程并行回收。
设置停顿时间
-XX:MaxGCPauseMillis 默认值是 200 毫秒
首先G1把内存区域分成了若干个相同大小的 Region 区，在执行回收的时候，根据标记阶段统计到的数据，计算出各个 Region 区的回收价值和成本，有了这些数据之后，就可以计算出回收哪几个Region价值最高，且符合用户预期的停顿时间。