地址：https://blog.csdn.net/shlgyzl/article/details/95041113 (写的也不太好)

1.引言

我们知道java在C语言的基础上演变而来。java垃圾回收机制是java和C等语言的一个重要区别，让java程序员可以不用像C++程序员那样为内存回收而提心吊胆，而是专注于业务逻辑。在介绍垃圾回收机制之前我们首先要介绍下jvm。jvm是Java Virtual Machine（Java虚拟机）的缩写。

它是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台操作系统相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。

G1与CMS垃圾回收器区别 - 图1

这张图相信大家都很熟悉。他就是Java运行时数据区。主要分为五个区域。线程共享的有,1.方法区(jdk1.8后由元空间代替)：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据.2.堆：此内存区域的唯一目的就是存放对象实例，几乎所有对象实例都在这里分配内存。存放new生成的对象和数组，它是jvm管理的最大一块内存区域。我们的垃圾回收器，大部分是要与它进行打交道的。线程私有的区域有3.程序计数器：指向当前线程正在执行的字节码指令行数等。异常跳转等功能的实现就是依赖程序计数器。4.虚拟机栈是Java执行方法的内存模型。每个方法被执行的时候，都会创建一个栈帧，把栈帧压人栈，当方法正常返回或者抛出未捕获的异常时，栈帧就会出栈。
（1）栈帧：栈帧存储方法的相关信息，包含局部变量数表、返回值、操作数栈、动态链接
a、局部变量表：包含了方法执行过程中的所有变量。局部变量数组所需要的空间在编译期间完成分配，在方法运行期间不会改变局部变量数组的大小。
b、返回值：如果有返回值的话，压入调用者栈帧中的操作数栈中，并且把PC的值指向 方法调用指令 后面的一条指令地址。
c、操作数栈：操作变量的内存模型。操作数栈的最大深度在编译的时候已经确定（写入方法区code属性的max_stacks项中）。操作数栈的的元素可以是任意Java类型，包括long和double，32位数据占用栈空间为1，64位数据占用2。方法刚开始执行的时候，栈是空的，当方法执行过程中，各种字节码指令往栈中存取数据。
d、动态链接：每个栈帧都持有在运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态链接。

2.垃圾回收管理的内存区域

通过上述我们可以知道堆内存是jvm管理的最大的一块内存区域。如下图G1与CMS垃圾回收器区别 - 图2

这张图就是目前分代垃圾回收算法的内存划分方式(1.8后已经弱化了”代”的物理概念了参见G1垃圾回收器)。那么垃圾回收算法是如何演变到现在这个样子呢？首先要如何定义jvm中的内存垃圾。

1.引用计数法是一个比较好的方法，就是记录对象是否被其他对象引用，当对象没有被其他对象引用就说明这个对象已经可以作为垃圾进行回收了。但同时也有一个显而易见的缺陷—无法解决循环引用(在此想到另外一个问题，spring如何初始化循环依赖的对象的？在另外的博客中会有相关整理)。基于这个缺陷，目前主流判定java对象是否为垃圾，主要使用的是

2.可达性分析算法：通过一系列“GC Roots”对象作为起点进行搜索，如果在“GC Roots”和一个对象之间没有可达路径，则称该对象是不可达的。不可达对象不一定会成为可回收对象。进入DEAD状态的线程还可以恢复，GC不会回收它的内存。

主要分为俩个阶段：
（1） 第一个阶段是可达性分析，分析该对象是否可达
（2） 第二个阶段是当对象没有重写finalize()方法或者finalize()方法已经被调用过，虚拟机认为该对象不可以被救活，因此回收该对象。那么哪些对象可以被当作GC ROOT对象呢？

GC ROOT对象：
（1） 虚拟机栈（栈帧中本地变量表）中引用的对象
（2） 方法区中静态属性引用的对象
（3） 方法区中常量引用的对象
（4） 本地方法栈中Native方法引用的对象。

以上是针对堆中对象是否可回收的判断。方法区中内存的回收主要是废弃常量和无用的类。 回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，若字符串“abc”已经进入常量池中，但当前系统没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用该字面量，若发生内存回收，且必要的话，该“abc”就会被系统清理出常量池。常量池中其他的类（接口）、方法、字段的符号引用与此类似。满足下面三个条件：

  • 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
  • 加载该类的ClassLoader已经被回收；
  • 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

3.常见的垃圾回收算法

1、Mark-Sweep（标记-清除算法）：
（1）思想：标记清除算法分为两个阶段，标记阶段和清除阶段。标记阶段任务是标记出所有需要回收的对象，清除阶段就是清除被标记对象的空间。
（2）优缺点：实现简单，容易产生内存碎片
2、Copying（复制清除算法）：
（1）思想：将可用内存划分为大小相等的两块，每次只使用其中的一块。当进行垃圾回收的时候了，把其中存活对象全部复制到另外一块中，然后把已使用的内存空间一次清空掉。
（2）优缺点：不容易产生内存碎片；可用内存空间少；存活对象多的话，效率低下。
3、Mark-Compact（标记-整理算法）：
（1）思想：先标记存活对象，然后把存活对象向一边移动，然后清理掉端边界以外的内存。
（2）优缺点：不容易产生内存碎片；内存利用率高；存活对象多并且分散的时候，移动次数多，效率低下

4、分代收集算法：（目前大部分JVM的垃圾收集器所采用的算法）：

4.1 年轻代（Young Generation）的回收算法 (回收主要以Copying为主)
a) 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

  1.      b) 新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。当创建对象，向Eden区申请内存时，如果Eden区满了，就进行minor GC。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时 survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。
  3.      c) 当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。
  5.      d) 新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

4.2 年老代（Old Generation）的回收算法（回收主要以Mark-Compact为主）

  1.     a) 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
  3.     b) 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

这个过程有个高频的面试题就是minor gc和full gc发生的时机：

Minor GC触发条件：当Eden区满时，触发Minor GC。

Full GC触发条件：
（1）调用System.gc时，系统建议执行Full GC，但是不必然执行
（2）老年代空间不足
（3）方法区(1.8之后改为元空间)空间不足
（4）创建大对象，比如数组，通过Minor GC后，进入老年代的平均大小大于老年代的可用内存
（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

4.垃圾回收器，CMS和G1

4.1 CMS垃圾回收器

1.CMS与G1都是并发回收，多线程分阶段回收，只有某阶段会stw；2.CMS只会回收老年代和永久代（1.8开始为元数据区，需要设置CMSClassUnloadingEnabled），不会收集年轻代；年轻带只能配合Parallel New或Serial回收器； CMS是一种预处理垃圾回收器，它不能等到old内存用尽时回收，需要在内存用尽前，完成回收操作，否则会导致并发回收失败；所以CMS垃圾回收器开始执行回收操作，有一个触发阈值，默认是老年代或永久带达到92%；

CMS 处理过程有七个步骤（这也是面试常问的问题，包括哪俩个阶段会STW）：
1. 初始标记(CMS-initial-mark) ,会导致STW； 初始标记阶段就是标记老年代中的GC ROOT对象和与GC ROOT对象关联的对象给标记出来。

  1. 并发标记(CMS-concurrent-mark)，与用户线程同时运行；因 为是并发运行的，在运行期间会发生新生代的对象晋升到老年代、或者是直接在老年代分配对象、或者更新老年代对象的引用关系等等，对于这些对象，都是需要进行重新标记的，否则有些对象就会被遗漏，发生漏标的情况。为了提高重新标记的效率，该阶段会把上述对象所在的Card标识为Dirty，后续只需扫描这些Dirty Card的对象，避免扫描整个老年代；
    并发标记阶段只负责将引用发生改变的Card标记为Dirty状态，不负责处理；

  2. 预清理（CMS-concurrent-preclean），与用户线程同时运行；

  3. 可被终止的预清理（CMS-concurrent-abortable-preclean） 与用户线程同时运行；

  4. 重新标记(CMS-remark) ，会导致STW； 这个阶段会导致第二次stop the word，该阶段的任务是完成标记整个年老代的所有的存活对象。

这个阶段，重新标记的内存范围是整个堆，包含_young_gen和_old_gen。为什么要扫描新生代呢，因为对于老年代中的对象，如果被新生代中的对象引用，那么就会被视为存活对象，即使新生代的对象已经不可达了，也会使用这些不可达的对象当做cms的“gc root”，来扫描老年代； 因此对于老年代来说，引用了老年代中对象的新生代的对象，也会被老年代视作“GC ROOTS”:当此阶段耗时较长的时候，可以加入参数-XX:+CMSScavengeBeforeRemark，在重新标记之前，先执行一次ygc，回收掉年轻带的对象无用的对象，并将对象放入幸存带或晋升到老年代，这样再进行年轻带扫描时，只需要扫描幸存区的对象即可，一般幸存带非常小，这大大减少了扫描时间

由于之前的预处理阶段是与用户线程并发执行的，这时候可能年轻带的对象对老年代的引用已经发生了很多改变，这个时候，remark阶段要花很多时间处理这些改变，会导致很长stop the word，所以通常CMS尽量运行Final Remark阶段在年轻代是足够干净的时候。另外，还可以开启并行收集：-XX:+CMSParallelRemarkEnabled。来提高这个阶段的效率

  1. 并发清除(CMS-concurrent-sweep)，与用户线程同时运行；

通过以上5个阶段的标记，老年代所有存活的对象已经被标记并且现在要通过Garbage Collector采用清扫的方式回收那些不能用的对象了。
这个阶段主要是清除那些没有标记的对象并且回收空间；由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。

  1. 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行；

CMS垃圾回收器的优化：

1.减少remark阶段停顿

一般CMS的GC耗时 80%都在remark阶段，如果发现remark阶段停顿时间很长，可以尝试添加该参数：-XX:+CMSScavengeBeforeRemark

在执行remark操作之前先做一次ygc，目的在于减少ygen对oldgen的无效引用，降低remark时的开销。

2.内存碎片

CMS是基于标记-清除算法的，只会将标记为为存活的对象删除，并不会移动对象整理内存空间，会造成内存碎片，这时候我们需要用到这个参数;-XX:CMSFullGCsBeforeCompaction=n

3.promotion failed与解决方法

过早提升与提升失败
在 Minor GC 过程中，Survivor Unused 可能不足以容纳 Eden 和另一个 Survivor 中的存活对象， 那么多余的将被移到老年 代， 称为过早提升（Premature Promotion）,这会导致老年代中短期存活对象的增长， 可能会引发严重的性能问题。 再进一 步， 如果老年代满了， Minor GC 后会进行 Full GC， 这将导致遍历整个堆， 称为提升失败（Promotion Failure）。
早提升的原因
1. Survivor空间太小，容纳不下全部的运行时短生命周期的对象，如果是这个原因，可以尝试将Survivor调大，否则端生命周 期的对象提升过快，导致老年代很快就被占满，从而引起频繁的full gc；
2. 对象太大，Survivor和Eden没有足够大的空间来存放这些大象；

提升失败原因
当提升的时候，发现老年代也没有足够的连续空间来容纳该对象。
为什么是没有足够的连续空间而不是空闲空间呢？
老年代容纳不下提升的对象有两种情况：
1. 老年代空闲空间不够用了；
2. 老年代虽然空闲空间很多，但是碎片太多，没有连续的空闲空间存放该对象；

解决方法
1. 如果是因为内存碎片导致的大对象提升失败，cms需要进行空间整理压缩；
2. 如果是因为提升过快导致的，说明Survivor 空闲空间不足，那么可以尝试调大 Survivor；
3. 如果是因为老年代空间不够导致的，尝试将CMS触发的阈值调低；
4.增加线程数

CMS默认启动的回收线程数目是 (ParallelGCThreads + 3)/4) ，这里的ParallelGCThreads是年轻代的并行收集线程数，感觉 有 点怪怪的；
年轻代的并行收集线程数默认是(ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)，可以通过-XX:ParallelGCThreads= N 来调整；
如果要直接设定CMS回收线程数，可以通过-XX:ParallelCMSThreads=n，注意这个n不能超过cpu线程数，需要注意的是增加 gc线程数，就会和应用争抢资源；

4.2 G1垃圾回收器

4.2.1 G1垃圾回收器相关数据结构

1.在HotSpot的实现中，整个堆被划分成2048左右个Region。每个Region的大小在1-32MB之间，具体多大取决于堆的大小。

2.对于Region来说，它会有一个分代的类型，并且是唯一一个。即，每一个Region，它要么是young的，要么是old的。还有一类十分特殊的Humongous。所谓的Humongous，就是一个对象的大小超过了某一个阈值——HotSpot中是Region的1/2，那么它会被标记为Humongous。

G1与CMS垃圾回收器区别 - 图3

每一个分配的Region，都可以分成两个部分，已分配的和未被分配的。它们之间的界限被称为top。总体上来说，把一个对象分配到Region内，只需要简单增加top的值。这个做法实际上就是bump-the-pointer。

G1与CMS垃圾回收器区别 - 图4

即每一次回收都是回收N个Region。这个N是多少，主要受到G1回收的效率和用户设置的软实时目标有关。每一次的回收，G1会选择可能回收最多垃圾的Region进行回收。与此同时，G1回收器会维护一个空间Region的链表。每次回收之后的Region都会被加入到这个链表中。
每一次都只有一个Region处于被分配的状态中，被称为current region。在多线程的情况下，这会带来并发的问题。G1回收器采用和CMS一样的TLABs的手段。即为每一个线程分配一个Buffer，线程分配内存就在这个Buffer内分配。但是当线程耗尽了自己的Buffer之后，需要申请新的Buffer。这个时候依然会带来并发的问题。G1回收器采用的是CAS（Compate And Swap）操作。

3.卡片 Card

在每个分区内部又被分成了若干个大小为512 Byte卡片(Card)，标识堆内存最小可用粒度所有分区的卡片将会记录在全局卡片表(Global Card Table)中，分配的对象会占用物理上连续的若干个卡片，当查找对分区内对象的引用时便可通过记录卡片来查找该引用对象(见RSet)。每次对内存的回收，都是对指定分区的卡片进行处理。

4.RS(Remember Set)

RS(Remember Set)是一种抽象概念，用于记录从非收集部分指向收集部分的指针的集合。
在传统的分代垃圾回收算法里面，RS(Remember Set)被用来记录分代之间的指针。在G1回收器里面，RS被用来记录从其他Region指向一个Region的指针情况。因此，一个Region就会有一个RS。这种记录可以带来一个极大的好处：在回收一个Region的时候不需要执行全堆扫描，只需要检查它的RS就可以找到外部引用，而这些引用就是initial mark的根之一。

那么，如果一个线程修改了Region内部的引用，就必须要去通知RS，更改其中的记录。为了达到这种目的，G1回收器引入了一种新的结构，CT(Card Table)——卡表。每一个Region，又被分成了固定大小的若干张卡(Card)。每一张卡，都用一个Byte来记录是否修改过。卡表即这些byte的集合。实际上，如果把RS理解成一个概念模型，那么CT就可以说是RS的一种实现方式。

在RS的修改上也会遇到并发的问题。因为一个Region可能有多个线程在并发修改，因此它们也会并发修改RS。为了避免这样一种冲突，G1垃圾回收器进一步把RS划分成了多个哈希表。每一个线程都在各自的哈希表里面修改。最终，从逻辑上来说，RS就是这些哈希表的集合。哈希表是实现RS的一种通常的方式之一。它有一个极大的好处就是能够去除重复。这意味着，RS的大小将和修改的指针数量相当。而在不去重的情况下，RS的数量和写操作的数量相当。

G1与CMS垃圾回收器区别 - 图5

4.2.2 G1垃圾回收器执行步骤：

1、初始标记；
初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS的值，让下一个阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这一阶段需要停顿线程，但是耗时很短，

2、并发标记；
并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段时耗时较长，但可与用户程序并发执行。

3、最终标记；
最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remenbered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这一阶段需要停顿线程，但是可并行执行。

4、筛选回收
最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。

4.3 CMS和G1的区别
面试如果把上述的都讲清楚。面试官估计也差不多能换个话题了。如果要继续深入问的话请参考CMS垃圾回收器详解，
G1垃圾回收器详解，详解 JVM Garbage First(G1) 垃圾收集器

参考文章：
百度百科：JVM
JVM 完整深入解析
方法区的垃圾回收
JVM内存管理，Minor GC和Full GC触发机制总结
CMS垃圾回收器详解
G1垃圾回收器详解
详解 JVM Garbage First(G1) 垃圾收集器
CMS和G1的对比分析