大白话说就是垃圾回收机制，内存空间是有限的，你创建的每个对象和变量都会占据内存，gc做的就是对象清除将内存释放出来，这就是GC要做的事。
说起垃圾回收的场所，了解过JVM（Java Virtual Machine Model）内存模型的朋友应该会很清楚，堆是Java虚拟机进行垃圾回收的主要场所，其次要场所是方法区。
Java将堆内存分为3大部分：新生代、老年代和永久代，其中新生代又进一步划分为Eden、S0、S1(Survivor)三个区
我们创建的对象会优先在Eden分配，如果是大对象（很长的字符串数组）则可以直接进入老年代。虚拟机提供一个
-XX:PretenureSizeThreadhold参数，令大于这个参数值的对象直接在老年代中分配，避免在Eden区和两个Survivor区发生大量的内存拷贝。
另外，长期存活的对象将进入老年代，每一次MinorGC（年轻代GC），对象年龄就大一岁，默认15岁晋升到老年代，通过
-XX:MaxTenuringThreshold设置晋升年龄。
堆内存上的对象回收也叫做垃圾回收，那么垃圾回收什么时候开始呢？
垃圾回收主要是完成清理对象，整理内存的工作。上面说到GC经常发生的区域是堆区，堆区还可以细分为新生代、老年代。新生代还分为一个Eden区和两个Survivor区。垃圾回收分为年轻代区域发生的Minor GC和老年代区域发生的Full GC，分别介绍如下。
Minor GC（年轻代GC）:
对象优先在Eden中分配，当Eden中没有足够空间时，虚拟机将发生一次Minor GC，因为Java大多数对象都是朝生夕灭，所以Minor GC非常频繁，而且速度也很快。
Full GC（老年代GC）:
Full GC是指发生在老年代的GC，当老年代没有足够的空间时即发生Full GC，发生Full GC一般都会有一次Minor GC。
接下来，我们来看关于内存分配与回收的两个重要概念吧。
动态对象年龄判定：
如果Survivor空间中相同年龄所有对象的大小总和大于Survivor空间的一半，那么年龄大于等于该对象年龄的对象即可晋升到老年代，不必要等到-XX:MaxTenuringThreshold。
空间分配担保：
发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小。如果大于，则进行一次Full GC（老年代GC），如果小于，则查看HandlePromotionFailure设置是否允许担保失败，如果允许，那只会进行一次Minor GC，如果不允许，则改为进行一次Full GC。
Eden，S0，S1比例8:1:1
这个我用别人说的话解释一下：
链接：https://www.jianshu.com/p/2caad185ee1f
为什么需要Survivor空间。我们看看如果没有 Survivor 空间的话，垃圾收集将会怎样进行：一遍新生代 gc 过后，不管三七二十一，活着的对象全部进入老年代，即便它在接下来的几次 gc 过程中极有可能被回收掉。这样的话老年代很快被填满， Full GC 的频率大大增加。我们知道，老年代一般都会被规划成比新生代大很多，对它进行垃圾收集会消耗比较长的时间；如果收集的频率又很快的话，那就更糟糕了。基于这种考虑，虚拟机引进了“幸存区”的概念：如果对象在某次新生代 gc 之后任然存活，让它暂时进入幸存区；以后每熬过一次 gc ，让对象的年龄＋1，直到其年龄达到某个设定的值（比如15岁）， JVM 认为它很有可能是个“老不死的”对象，再呆在幸存区没有必要（而且老是在两个幸存区之间反复地复制也需要消耗资源），才会把它转移到老年代。
Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。
为什么 Survivor 分区不能是 1 个？
如果 Survivor 分区是 1 个的话，假设我们把两个区域分为 1:1，那么任何时候都有一半的内存空间是闲置的，显然空间利用率太低不是最佳的方案。
但如果设置内存空间的比例是 8:2 ，只是看起来似乎“很好”，假设新生代的内存为 100 MB（ Survivor 大小为 20 MB ），现在有 70 MB 对象进行垃圾回收之后，剩余活跃的对象为 15 MB 进入 Survivor 区，这个时候新生代可用的内存空间只剩了 5 MB，这样很快又要进行垃圾回收操作，显然这种垃圾回收器最大的问题就在于，需要频繁进行垃圾回收。
为什么 Survivor 分区是 2 个？
刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）。S0和Eden被清空，然后下一轮S0与S1交换角色，如此循环往复。如果对象的复制次数达到16次，该对象就会被送到老年代中。下图中每部分的意义和上一张图一样，就不加注释了。
上述机制最大的好处就是，整个过程中，永远有一个survivor space是空的，另一个非空的survivor space无碎片。
那么，Survivor为什么不分更多块呢？比方说分成三个、四个、五个?显然，如果Survivor区再细分下去，每一块的空间就会比较小，很容易导致Survivor区满
总结
根据上面的分析可以得知，当新生代的 Survivor 分区为 2 个的时候，不论是空间利用率还是程序运行的效率都是最优的，所以这也是为什么 Survivor 分区是 2 个的原因了。
判断一个对象是否应该被回收，主要是看其是否还有引用。判断对象是否存在引用关系的方法包括引用计数法以及可达性分析。
是一种比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只需要收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。
可达性分析的基本思路就是通过一系列可以做为root的对象作为起始点，从这些节点开始向下搜索。当一个对象到root节点没有任何引用链接时，则证明此对象是可以被回收的。以下对象会被认为是root对象：
HotSpot 虚拟机采用了可达性分析来进行内存回收，常见的回收算法有标记-清除算法，复制算法和标记整理算法。
标记-清除算法（Mark-Sweep）：
标记-清除算法执行分两阶段。
第一阶段：从引用根节点开始标记所有被引用的对象，
第二阶段：遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，并且会产生内存碎片。
缺点：
复制算法：
复制算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。复制算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
缺点：
标记-整理算法：
标记-整理算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，
第一阶段从根节点开始标记所有被引用对象，
第二阶段遍历整个堆，清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。
JVM中的垃圾收集器主要包括7种，即Serial，Serial Old，ParNew，Parallel Scavenge，Parallel Old以及CMS，G1收集器。如下图所示：
1、Serial收集器：
Serial收集器是一个单线程的垃圾收集器，并且在执行垃圾回收的时候需要 Stop The World。虚拟机运行在Client模式下的默认新生代收集器。Serial收集器的优点是简单高效，对于限定在单个CPU环境来说，Serial收集器没有多线程交互的开销。
2、Serial Old收集器：
Serial Old是Serial收集器的老年代版本，也是一个单线程收集器。主要也是给在Client模式下的虚拟机使用。在Server模式下存在主要是做为CMS垃圾收集器的后备预案，当CMS并发收集发生Concurrent Mode Failure时使用。
3、ParNew收集器：
ParNew是Serial收集器的多线程版本，新生代是并行的（多线程的），老年代是串行的（单线程的），新生代采用复制算法，老年代采用标记整理算法。可以使用参数：-XX：UseParNewGC使用该收集器，使用 -XX：ParallelGCThreads可以限制线程数量。
4、Parallel Scavenge垃圾收集器：
Parallel Scavenge是一种新生代收集器，使用复制算法的收集器，而且是并行的多线程收集器。Paralle收集器特点是更加关注吞吐量（吞吐量就是cpu用于运行用户代码的时间与cpu总消耗时间的比值）。可以通过-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间；通过-XX:GCTimeRatio参数直接设置吞吐量大小；通过-XX:+UseAdaptiveSizePolicy参数可以打开GC自适应调节策略，该参数打开之后虚拟机会根据系统的运行情况收集性能监控信息，动态调整虚拟机参数以提供最合适的停顿时间或者最大的吞吐量。自适应调节策略是Parallel Scavenge收集器和ParNew的主要区别之一。
5、Parallel Old收集器：
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法。
CMS收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于标记-清除算法实现的，是一种老年代收集器，通常与ParNew一起使用。
CMS的垃圾收集过程分为4步：
那么问题来了，如果在重新标记之前刚好发生了一次MinorGC，会不会导致重新标记阶段Stop the World时间太长？
答：不会的，在并发标记阶段其实还包括了一次并发的预清理阶段，虚拟机会主动等待年轻代发生垃圾回收，这样可以将重新标记对象引用关系的步骤放在并发标记阶段，有效降低重新标记阶段Stop The World的时间。
CMS以降低垃圾回收的停顿时间为目的，很显然其具有并发收集，停顿时间低的优点。
接下来，我们先看下上边介绍的浮动垃圾是怎么产生的吧。
浮动垃圾：
由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。
7、G1（Garbage-First）收集器：
G1收集器将新生代和老年代取消了，取而代之的是将堆划分为若干的区域，每个区域都可以根据需要扮演新生代的Eden和Survivor区或者老年代空间，仍然属于分代收集器，区域的一部分包含新生代，新生代采用复制算法，老年代采用标记-整理算法。
通过将JVM堆分为一个个的区域（region）,G1收集器可以避免在Java堆中进行全区域的垃圾收集。G1跟踪各个region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据回收时间来优先回收价值最大的region。
G1收集器的特点：
和CMS收集器类似，G1收集器的垃圾回收工作也分为了四个阶段：
其中，筛选回收阶段首先对各个Region的回收价值和成本进行计算，根据用户期望的GC停顿时间来制定回收计划。
1.首先说如果看怎么看
我的版本是jdk1.8
java -XX:+PrintCommandLineFlags -version
2.jdk1.8和1.9用的版本
jdk1.8默认的新生代垃圾收集器：Parallel Scavenge，老年代：Parallel Old
jdk1.9 默认垃圾收集器G1
