JVM、Minor GC ，Full GC 触发条件是什么？、GC Roots的选择依据、被GC判断为不可达的对象一定会被回收吗

jdk1.8默认的垃圾收集器

Parallel Scavenge 收集器。
Parallel Scavenge 收集器使用标记-复制算法的多线程收集器，新生代采用标记-复制算法，老年代采用标记-整理算法。

• Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）（所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值）
• CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）
  $JDK1.8默认使用的是ParallelScavenge(新生代)+ParallelOld（老年代）$，如果指定了-XX:+UseParallelGC 参数，则默认指定了-XX:+UseParallelOldGC，可以使用-XX:-UseParallelOldGC 来禁用该功能。
  java -XX:+PrintFlagsFinal -version |FINDSTR /i ":" 可以看到1.8默认的是 UseParallelGC
  

CMS 收集器

• CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。
• CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
  整个过程分为四个步骤：
• 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
• 并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
• 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
• 并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。
  
  从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。
  但是它有下面三个明显的缺点：
• 对 CPU 资源敏感；
• 无法处理浮动垃圾；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

Minor GC ，Full GC 触发条件是什么？

• 从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC；
• 对老年代GC称为Major GC；
• 而Full GC是对整个堆来说的；

Minor GC触发条件：

当Eden区满时，触发Minor GC。

Full GC触发条件：

（1）System.gc()方法的调用

此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。

（2）老年代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

（3）方法区空间不足

JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：
java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

（4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存

如果发现统计数据说之前Minor GC的平均晋升大小比目前old gen剩余的空间大，则不会触发Minor GC而是转为触发full GC

（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。
System.gc()这个东西提醒的是Full GC，不是Minor GC。
参考：JVM内存管理，Minor GC和Full GC触发机制总结

GC Roots的选择依据

GC Roots实例参考：GC Roots

一、选择这些对象的依据是什么？

当前栈帧中的引用型变量；静态变量引用的对象；本地方法栈JNI的引用对象，很明显是当前存活对象。所以他们比如是GC Roots的一部分。方法区中的常量引用对象，在当前可能存活，因此，也可能是GC roots的一部分。还有其他一些对象也可能是GC Roots的一部分，比如被classloader加载的class对象，monitor的对象，被JVM持有的对象等等，这些都需要视当前情况而定。

二、GC管理的主要区域是Java堆，一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC roots,被GC roots引用的对象不被GC回收。

被GC判断为不可达的对象一定会被回收吗

即使在可达性分析算法中不可达的对象,也并非是“非死不可”的,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。

• 当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行finilize()方法”。(即意味着直接回收)
• 如果这个对象被判定为有必要执行finalize()方法,那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样做的原因是,如果一个对象在finalize()方法中执行缓慢,或者发生了死循环(更极端的情况),将很可能会导致F-Queue队列中其他对象永久处于等待,甚至导致整个内存回收系统崩溃。
  finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。
  参考：finilize()方法与GC