深入理解JVM虚拟机-对象引用，GC与内存分配回收

在堆里面存放着 Java 世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象），那在GC是如何判断一个对象是否存活还是死亡呢？

1.1 引用计数算法（Reference Counting）

很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。这就是引用计数算法（Reference Counting）。 引用计数算法（Reference Counting）的实现简单，判定效率也很高， 但主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。

相互循环引用即为对象A中拿着对象B的引用，对象B中拿着对象A的引用。

1.2 可达性分析算法（Reachability Analysis）

在java中，是通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。 如图示，对象object 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达 的，所以它们将会被判定为是可回收的对象。

在Java语言中，可作为GC Roots的对象包括下面几种：

1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
2. 方法区中类静态属性引用的对象。
3. 方法区中常量引用的对象。
4. 本地方法栈中JNI（即一般说的Native方法）引用的对象。

1.3 对象引用

在JDK1.2之前，Java中的引用的定义是如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。这种定义太过狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态。 在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为** 强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference) 4种**，这4种引用强度依次逐渐减弱。

1. 强引用 :是指在程序代码之中普遍存在的，类似“Object obj=new Object（）”这类的引 用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2. 软引用 :是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将 要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回 收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了 SoftReference 类来实现软引用。
3. 弱引用 :也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。在JDK 1.2之后，提供了 WeakReference 类来实现弱引用。
4. 虚引用 ：也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引 用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。 为一 个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知 。在 JDK 1.2之后，提供了 PhantomReference 类来实现虚引用。

1.4 死亡与自救

真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize（） 方法。当对象没有覆盖 finalize（） 方法，或者 finalize（） 方法已经被虚拟机调用过，这两种情况下对象都会被回收。 如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环，将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。

package com.wtj.myjvm;

/**
 * Created on 2019/4/11.
 *
 * @author wangtingjun
 * @since 1.0.0
 */

/**
 * 1.对象可以在被GC时自我拯救。
 * 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
 *
 * @author wtj
 */
public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
        System.out.println("yes,i am still alive：)");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize mehtod executed！");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable {
        SAVE_HOOK = new FinalizeEscapeGC();
        //对象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead：(");
        }
        //下面这段代码与上面的完全相同，但是这次自救却失败了
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，所以暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no,i am dead：(");
        }
    }
}
复制代码

运行结果：

finalize mehtod executed！
yes,i am still alive：)
no,i am dead：(
复制代码

从上面的代码可以看出，对象的 finalize（） 方法确实被GC收集器触发过，并且在被收集前成功逃脱了。 对象的finalize()方法最多只会被系统自动调用一次。

2 垃圾收集算法

2.1 标记-清除算法

标记-清除算法是最基础的收集算法之一，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。 它的主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2.2 复制算法

它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。 这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，运行高效。但代价是将内存缩小为原来的二分之一。 现在的商业虚拟机都采用这种收集算法来回收新生代，研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。 但是没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存进行分配担保（Handle Promotion）。即如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代 。

2.3 标记-整理算法（Mark-Compact）

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

2.4 分代收集算法（Generational Collection）

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

3 HotSpot虚拟机的算法

3.1 枚举根节点OopMap

HotSpot虚拟机使用可达性分析算法来判断一个对象的存活状态，如果逐个检查每个GC Roots节点，势必会消耗很多时间。并且这项分析工作必须在一个能确保一致性的快照中进行，即在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有Java执行线程（Sun将这件事情称为“Stop The World”）的其中一个重要原因。 在HotSpot的实现中，是使用一组称为OopMap的数据结构存放着对象引用，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

3.2 安全点 Safepoint

HotSpot通过OopMap可以快速的完成根节点的枚举，OopMap内容变化的指令非常多，如果为每一 条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。 实际上，HotSpot只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。 安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。

4 HotSpot使用的GC与内存分配回收

我使用的JDK版本是JDK1.8，通过命令 java -XX:+PrintCommandLineFlags -version 可以查看到虚拟机默认使用的垃圾收集器。

从参数 -XX:+UseParallelGC 可以看出，默认使用的垃圾收集器是 Parallel Scavenge（新生代）+ Serial Old（老年代）

。

4.1 Parallel Scavenge

Parallel Scavenge收集器是一个新生代收集器，他使用的是复制算法，并且是多线程的收集器。Parallel Scavenge的目标是打到一个可控制的吞吐量，也就是CPU用于运行用户代码的时间与CPU总耗时时间的比， Parallel Scavenge收集器也被称为“吞吐量优先”收集器。 Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis 参数以及直接设置吞吐量大小的 -XX：GCTimeRatio 参数。也可以通过参数 -XX：+UseAdaptiveSizePolicy 来开启自适应的调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息进行动态分配。

4.2 Serial Old

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。

4.3 CMS（Concurrent Mark Sweep）

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。 CMS收集器是基于“标记—清除”算法实现的，运作分为四个步骤： 初始标记（CMS initial mark） ； 并发标记（CMS concurrent mark） ； 重新标记（CMS remark） ； 并发清除（CMS concurrent sweep） 。其中并发标记和并发清除最为耗时，但可以与用户线程一起工作。

4.4 内存的分配与回收

java程序在运行的时候，会创建大量的对象，这些对象的生命周期可不相同，生命周期短的对象主要被分配在新生代的Eden（伊甸园）区上，少数情况下会被分配在老年代，分配规则并不百分百固定，对于生命周期长的对象则被分配在老年代。 年轻代 ：是主要存放新建的对象，年轻代的垃圾回收比较频繁。年轻代中分为一个Eden区和两个survior区（from和to），比例为8：1。年轻代中的对象寿命较短，使用的是 复制算法 。 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。 年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中 ，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

年老代 ：老年代，用于存放新生代中经过多次垃圾回收仍然存活的对象，也有可能是新生代分配不了内存的大对象会直接进入老年代。经过多次垃圾回收且年龄达到 MaxTenuringThreshold 的对象就会放入到老年代。 当老年代被放满的之后，虚拟机会进行垃圾回收，称之为Major GC。由于Major GC除并发GC外均需对整个堆进行扫描和回收，因此又称为Full GC， Full GC会导致程序的暂时停止，大量的Full GC会导致系统响应速度降低，而且引来巨大的风险 。 Perm Gen(永久代) (JDK1.8之后被元空间替代) ：Perm Gen全称是Permanent Generation space，称之为永久代， 其实就是这个方法区

，只不过在HotSpot虚拟机中常被称为永久代。

部分参考： www.cnblogs.com/haitaofeiya…