JVM （四）GC过程

程序计数器、虚拟机栈、本地方法栈都是随线程生灭，栈帧随着方法的进入和退出做入栈和出栈操作，实现了自动的内存清理，因此，内存垃圾回收主要集中于Java堆和方法区中。

GC整体流程示意图：

① 年轻代对象的移动

1，新创建的对象分配到eden区；

2，eden区满了触发minor gc，eden存活的对象被复制到from区（年龄+1），不存活的对象被回收；

3，当eden区再次满了，eden和from区的存活对象被复制到to区，from和to区交换。如果to区放不下，则晋升到老年代；

4，几次minor gc后，当对象的年龄达到阈值（-XX：MaxTenuringThreshold默认是15）之后，就会被从年轻代Promotion到老年代;

② minor gc和major gc的时机

1. 在新生代申请内存空间不足的时候触发垃圾回收；

2. 判断老年代剩余空间是否大于年轻代所使用的内存

    1. 老年代剩余空间 > 年轻代所使用空间，直接进行Minor GC；

    2. 老年代剩余空间 < 年轻代所使用空间，这个时候要看有没有设置担保机制（-XX:HandlePromotionFailure）

        1. 设置了担保机制，则比较每一次Minor GC后晋升到老年代的平均大小和老年代的剩余空间大小：

            1. 平均晋升对象大小 < 老年代剩余空间大小，这个时候就执行Minor GC；

            2. 平均晋升对象大小 > 老年代剩余空间大小，这个时候就先执行Major GC；

        2. 没设置担保机制，则先进行一次Major GC（防Minor GC后老年代放不下晋升对象）；

至于minor gc和major gc如何执行，那就是不同垃圾收集器做的事情了。

判断对象是否存活一般有两种方式：

在Java语言中，GC Roots包括：

是最基础的收集算法，是因为后续的收集算法都是基于这种思路。

分为“标记”和“清除”两个阶段：

优点：简单快捷；

缺点：内存碎片化严重

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

每次对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。

优点：内存碎片化问题得到部分解决；

缺点：内存的有效使用率太低。

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

优点：解决内存碎片化问题并且内存利用率大大提高；

缺点：内存需要不断地变动，效率变低。

严格来说并不是一种思想或理论，而是融合上述3种基础的算法思想，而产生的针对不同情况所采用不同算法的组合。

GC分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。

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

详见：JVM 垃圾收集器

在垃圾回收过程中经常涉及到对对象的挪动，导致需要对对象引用进行更新。为了保证引用更新的正确性，Java将暂停所有其他的线程，这种情况被称为“Stop-The-World”，导致系统全局停顿，会对系统性能存在影响。

在JVM启动参数的GC参数里加上-XX:+PrintGCApplicationStoppedTime，可以把全部的JVM停顿时间（不只是GC），打印在GC日志里。这个参数，可以打出几乎一切的停顿……

2016-08-22T00:19:49.559+0800: 219.140: Total time for which application threads were stopped: 0.0053630 seconds