如何看待Java 虚拟机的GC操作。

GC(Garbage Collect 垃圾回收)

GC分为 Young区的 Minor GC，Old区的Major GC , Young区和Old区的Full GC。

首先说说运行时数据区的垃圾回收问题

程序计数器、虚拟机栈、本地方法栈这三个区域都是随着线程创建/销毁而生/死的。栈中的栈桢随着方法的进入和退出而执行出栈和入栈操作的。每一个栈桢中分配多少内存基本上是在类结构确定下来事时就已知的，因此这三个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自己就回收了。而Java堆和方法区就不一样了， 一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才知道会创建那些对象，这部分内存分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

J方法区（或者HotSpot虚拟机中的永久代）进行垃圾收集的“性价比”一般比较低：在堆中，尤其是新生代中，常规应用进行一次垃圾收集一般可以回收70%-95%的空间，而永久代的垃圾收集率远低于此。
永久代的垃圾收集主要分为两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量回收为例，假如一个字符串“ABC”已经引入常量池中，但是当前系统没有任何一个string对象是叫ABC的（没有任何string对象引用常量池中的ABC常量），也没有其他地方引用这个字面量，如果在这时候发生内存回收，而且有必要的话，这个ABC常量就会被系统“请”出常量池。常量池中的其他类、接口、方法、字段的符号引用也与此类似。

谁是垃圾对象？

两种方式判断对象是否是来及对象：

引用计数法

对于某个对象而言，只要应用程序中持有改对象的引用，就说明改对象不是垃圾，如果一个对象没有任何指针对其引用，它就是垃圾了。
那如果AB相互持有引用，但是没用对象引用AB，就会导致AB永远也不会被回收？
所有这个引用计数法已经废弃了！

可达性分析

通过GC Root的对象，开始向下寻找，看某个对象是否可达。

what? （一脸懵…）
这个算法的基本思想是通过一系列名为“GC Root”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象那个刀片GC Root没有任何引用链相连时，则证明此对象是不可用的，会被作为垃圾回收掉。
GC Root是啥对象？
能作为GCRoot：类加载器，Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量

• 虚拟机栈（栈桢中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（一般说的Native方法）引用对象
  引用
  如果reference类型的数据中存储的数值代表的是另一个块内存中的起始地址，就称这块内存代表着一个引用。
  引用分为四种：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）
• 强引用就是指在程序代码之中普遍纯在的，类似Object object = new Object()这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收。如果这次回收了还没有足够的内存，才会抛出内存溢出异常。
• 弱引用也就用来描述非必要对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
• 虚引用也称为幽灵引用或幻影引用，它是最弱的一种 引用，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知。

垃圾收集器算法

标记-清除（Mark-Sweep）

1. 标记
   找出内存中许需要回收的对象，并把它们标记出来。
   此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时。
   
2. 清除
   清除掉被标记需要回收的对象，释放出对应的内存空间
   
   缺点

标记清除之后会产生大量不联系的内存碎片，空间碎片太多可能会导致以后在程序运行过程需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

1. 标记和清除两个过程都比较耗时，效率不高
2. 会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次的垃圾收集动作。

复制算法

将内存划分为两块相等的区域，每次只使用其中一块，如下

当其中一块内存使用完了， 就将还存活的对象复制到另一块上面，然后把已经使用过的内存空间一次清除掉。

缺点

空间利用率降低

标记-整理（Mark-Compact）

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都有100%存活的极端情况，所以老年代一般不能直接选用这种算法。

标记过程仍然与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清除掉边界以外的内存。

让所有存活的对象向一端移动，清理掉边界以外的内存。

分代收集算法

为了增加垃圾回收的效率，JVM会根据对象存活周期的不同将内存分为几块，堆中分为新生代和老年代。
这样可以根据各个年代的特点采用最适当的收集算法。
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记清除”或者“标记-整理”算法来进行回收。

Young区：复制算法（对象在被分配之后，可能生命周期比较短，young区复制率比较高）
Old区： 标记清除或标记整理（Old区对象存活时间比较长，复制来复制去没必要费时间，不如做标记在清理）

垃圾收集器

Serial收集器

Serial是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。

优点：简单高效，拥有很高的单线程收集效率
缺点：收集过程需要暂停所有线程
算法：复制算法
适用范围：新声代
应用： client模式下的默认新生代收集器

ParNew收集器

可以吧这个收集器理解为Serial收集器的多线程版本。多线程并行执行垃圾收集。

优点：在多CPU时，比Serial效率高。
缺点： 收集过程暂停所有应用线程，单CPU时比Serial效率差。
算法： 复制算法
适应范围： 新生代
应用：运行在Serial模式下的虚拟机中首选中的新生代收集器

Parallel Scavenge 收集器

paraller Scavenge 收集器是一个新生代收集器，它也是适应复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量 。

吞吐量 = 运行用户代码的时间 / 运行用户代码的时间 + 垃圾收集时间
比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量 =（100-1)/100 =99%
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。
-xx:MaxGCPauseMillis控制最大的垃圾收集停顿时间
-xx:GCRation 直接设置吞吐量大小

Serial Old收集器

Serial old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用“标记-整理算法”，运行过程和Serial收集器一样。

parallel Old 收集器

Parallel Old收集器是Parallel Scavenger收集器的老年代版本，使用多线程和“标记-整理算法”进行垃圾回收。

吞吐量优先

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。
采用的是“标记-清除算法”，整个过程分为4步。

1. 初始标记 CMS initial mark 标记GC Root能关联到的对象 Stop The World
2. 并发标记 CMS concurrent mark 进行GC Roots Tracing
3. 重新标记 CMS remark 修改并发标记因用户程序变动的内容 Stop The world
4. 并发清除 CMS concurrent sweep

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点： 并发收集，地停顿
缺点： 产生大量空间碎片，并发阶段会降低吞吐量

G1收集器

G1收集器在JDK 7正式作为商用的收集器
与前几个收集器相比，G1有以下特点

并发与并行
分代收集（仍然保留了分代的概念）
空间整合（整体上属于“标记-整理”算法，不会导致空间碎片）
可预测的停顿（比CMS更先进的地方在于能让使用这明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间 不的超过N毫秒）

使用G1收集器时，Java堆的内存布局与其他收集器又很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region（不需要链接）的集合。

工作过程可以分为如下几个步骤

• 初始标记（Initial Marking） 标记一下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程
• 并发标记（Concurrent Marking） 从 GC Roots 进行可达性分析，找出存活的对象，与用户线程并发执行
• 最终标记 （Final Marking） 修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程
• 筛选回收 （LiveData Counting and Evacuation）对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

垃圾收集器分类

• 串行收集器 -> Serial 和 Serial Old

只能有一个垃圾回收线程执行，用户线程暂停。使用于内存比较小的 嵌入式设备。

• 并行收集器[吞吐量优先] -> Parallel Scanvenge、Parallel Old

多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态，适用于科学计算，后台处理等交互场景。

• 并发收集器 [停顿时间优先] -> CMS G1

用户线程和垃圾收集线程同事执行（但并不一定是并行的，可能是交替执行），垃圾收集线程在执行的时候不会停顿用户线程的运行，适用于相对时间有要求的场景 比如web

小小知识点

吞吐量和停顿时间

• 停顿时间：垃圾收集器 进行 垃圾回收终端应用执行响应的时间
• 吞吐量： 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）

停顿时间越短就越适合需要和用户交互的程序，良好的相应速度能提升用户的体验
高吞吐则可以高效利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

这两个指标也是评价垃圾会收器好坏的标准，其实调优也就是观察这两个变量。

选择什么样的垃圾收集器

• 优先调整堆的大小让服务器自己来选择
• 如果内存小于100M，使用串行收集器
• 如果是单核，并且没有停顿时间要求，使用串行或JVM自己选
• 如果允许停顿时间超过1秒，选择并行或JVM自己选
• 如果响应时间更重要，并且不能超过1秒，使用并发收集器

G1收集器，是否使用G1收集器
JDK 7开始使用，JDK 8非常成熟，JDK 9 默认的垃圾收集器。

• 50%以上的堆被存活对象占用
• 对象分配和晋升的速度变化非常大
• 垃圾回收时间比较长

如何开启需要的垃圾收集器

串行

• -XX: +UseSerialGC
• -XX: +UseSerialOldGC
  并行（吞吐量优先）
• -XX: +UseParallelGC
• -XX: +UseParallelOldGC
  并发收集器（响应时间优先）
• -XX: +UseConcMarkSweepGC
• -XX: +UseG1GC