JVM 学习笔记(三) 垃圾收集器与内存分配策略

最新推荐文章于 2018-08-24 12:02:58 发布

Geek-Yan

最新推荐文章于 2018-08-24 12:02:58 发布

阅读量377

点赞数

分类专栏： jvm 文章标签： jvm 内存分配

本文链接：https://blog.csdn.net/bmwopwer1/article/details/70244828

版权

jvm 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

本博客主要讨论 Java 堆的垃圾收集以及内存分配策略。参考书籍《深入理解 Java 虚拟机》第二版

1. 如何判断对象可以被回收

1.1 如何判定对象是否存活

判断对象是否存活的算法有两种，引用计数法和可达性分析算法。

引用计数法：给对象一个引用计数器，每当有一个地方有引用时，计数器就加1。当引用失效时，计数器就减1，任何时刻计数器为0的对象就是不可能再被使用的。目前主流的 Java 虚拟机没有选用这种方法来管理内存，最主要的原因是它很难解决对象之间循环引用的问题。

下面通过代码案例来证明 JVM 不是通过引用计数法来管理内存的。

public class ReferenceCountingGC {
    public Object instance = null;
    private static final int _1MB = 1024 * 1024;
    /**
     * 这个成员属性的唯一意义就是占点内存,以便能在GC日志中看清楚是否被回收过
     */
    private byte[] bigSize = new byte[2 * _1MB];

    public static void testGC() {
        // 定义两个对象
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();

        // 给对象的成员赋值，即存在相互引用情况
        objA.instance = objB;
        objB.instance = objA;

        // 将引用设为空，即没有到堆对象的引用了
        objA = null;
        objB = null;

        // 进行垃圾回收
        System.gc();    
    }

    public static void main(String[] args) {
        testGC();    
    }
}

运行结果：

这里写图片描述

从运行结果可以看出， JVM 并不是因为这两个对象互相引用就不回收它们，说明 JVM 不采用引用计数法。

可达性分析法：通过一系列的称为”GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链( Reference Chain )，当一个对象到GC Roots 没有任何引用链相连接时，则证明此对象是不可用的。
- 在Java语言中，可以作为GCRoots的对象包括下面几种：
  1. 虚拟机栈（栈帧中的局部变量区，也叫做局部变量表）中引用的对象。
  2. 方法区中的类静态属性引用的对象。
  3. 方法区中常量引用的对象。
  4. 本地方法栈中JNI(Native方法)引用的对象。
- 下面给出一个GCRoots的例子，如下图，为GCRoots的引用链。
由图可知，obj8、obj9、obj10都没有到GCRoots对象的引用链，即便obj9和obj10之间有引用链，他们还是会被当成垃圾处理，可以进行回收。

1.2 对象的引用

总结：无论是哪种分析方法，判定对象是否存活都与引用有关。下面详细介绍 Java 的引用。
在 Java 中，引用分为强引用、软引用、弱引用、虚引用 4 种。

强引用：是指在程序的代码中，使用 new 关键字创建的对象。只要强引用存在，垃圾收集器永远不会回收掉被引用的对象。

Object obj = new Object();

软引用：非必须引用，内存溢出之前进行回收，可以通过以下代码实现：

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;
sf.get();//有时候会返回null

这时候sf是对obj的一个软引用，通过sf.get()方法可以取到这个对象，当然，当这个对象被标记为需要回收的对象时，则返回null；软引用主要用户实现类似缓存的功能，在内存足够的情况下直接通过软引用取值，无需从繁忙的真实来源查询数据，提升速度；当内存不足时，自动删除这部分缓存数据，从真正的来源查询这些数据。

弱引用：非必需引用，强度比软引用弱，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;
wf.get();//有时候会返回null
wf.isEnQueued();//返回是否被垃圾回收器标记为即将回收的垃圾

虚引用：不会对对象的生存时间构成影响，无法通过虚引用来取得一个对象实例。虚引用主要用于检测对象是否已经从内存中删除。

Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj);
obj=null;
pf.get();//永远返回null
pf.isEnQueued();//返回是否从内存中已经删除

1.3 如何判断对象生存还是死亡

　　即使在可达性分析算法中不可达的对象，也不是非死不可的，要真正宣告一个对象死亡，至少要经历两次标记过程。

如果对象在进行可达性分析后发现没有与GCRoots相连的引用链，则该对象被第一次标记并进行一次筛选，筛选条件为是否有必要执行该对象的finalize方法，若对象没有覆盖finalize方法或者该finalize方法是否已经被虚拟机执行过了，则均视作不必要执行该对象的finalize方法，即该对象将会被回收。反之，若对象覆盖了finalize方法并且该finalize方法并没有被执行过，那么，这个对象会被放置在一个叫F-Queue的队列中，之后会由虚拟机自动建立的、优先级低的Finalizer线程去执行，而虚拟机不必要等待该线程执行结束，即虚拟机只负责建立线程，其他的事情交给此线程去处理。
对F-Queue中对象进行第二次标记，如果对象在finalize方法中拯救了自己，即关联上了GCRoots引用链，如把this关键字赋值给其他变量，那么在第二次标记的时候该对象将从“即将回收”的集合中移除，如果对象还是没有拯救自己，那就会被回收。

如下代码演示了一个对象如何在finalize方法中拯救了自己，然而，它只能拯救自己一次，第二次就被回收了。具体代码如下

/*
 * 此代码演示了两点：
 * 1.对象可以再被GC时自我拯救
 * 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
 * */

public class FinalizeEscapeGC {
    public String name;
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public FinalizeEscapeGC() {
    }

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

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

    @Override
    public String toString() {
        return name;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();
        System.out.println(SAVE_HOOK);
        // 对象第一次拯救自己
        SAVE_HOOK = null;
        System.out.println(SAVE_HOOK);
        System.gc();
        // 因为finalize方法优先级很低，所以暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead : (");
        }

        // 下面这段代码与上面的完全相同,但是这一次自救却失败了
        // 一个对象的finalize方法只会被调用一次
        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 method executed!
　yes, i am still alive :)
　no, i am dead : (

由结果可知，该对象拯救了自己一次，第二次没有拯救成功，因为对象的finalize方法最多被虚拟机调用一次。

1.4 回收方法区

　　方法区（永久代）的垃圾回收主要回收两部分内容：1. 废弃常量。2. 无用的类。既然进行垃圾回收，就需要判断哪些是废弃常量，哪些是无用的类。

　　如何判断废弃常量呢？以字面量回收为例，如果一个字符串“java”已经进入常量池，但是当前系统没有任何一个String对象引用了叫做“java”的字面量，那么，如果发生垃圾回收并且有必要时，“java”就会被系统移出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

　　如何判断无用的类呢？需要满足以下三个条件

该类的所有实例都已经被回收，即Java堆中不存在该类的任何实例。
加载该类的ClassLoader已经被回收。
该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

满足以上三个条件的类可以进行垃圾回收，但是并不是无用就被回收，虚拟机提供了一些参数供我们配置。

2. 垃圾收集算法

2.1 标记—清除( Mark-Sweep )算法

这里写图片描述

算法分为标记和清除两个阶段：首先标记出所有要回收的对象，在标记完成后统一回收所有被标记的对象。
主要不足有两个：
1. 效率问题，标记和清除两个过程效率都不高。
2. 空间问题，会产生大量不连续的内存碎片，导致后续要分配大对象时，无法找到足够连续的内存而不得不提前出发一次GC。

2.2 复制算法

这里写图片描述

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

好处：只要对半个区域进行内存回收，内存分配时不用考虑内存碎片等复杂情况。
缺点：将内存分为原来的一半，代价有些略高。

　　现在的商业虚拟机都采用这种算法来回收新生代。将内存分为一块较大的 Eden 空间和两块较小的 Survior 空间，每次使用 Eden 和其中一块 Survior 。HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90% ( 80%+10% )，只有 10% 的内存会被“浪费”。

2.3 标记—整理算法

这里写图片描述

　　复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。标记整理算法的标记过程类似标记清除算法，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，类似于磁盘整理的过程，该垃圾回收算法适用于对象存活率高的场景（老年代）。

2.4 分代收集算法

　　当前的商业虚拟机都采用这种算法，分代收集是根据对象存活周期的不同将内存划分为几块，一般是分为新生代和老年代。在新生代中采用复制算法，而老年代中使用标记—清理或者标记—整理算法。

3. 垃圾收集器

垃圾收集器是内存回收的具体实现，HotSpot虚拟机包含的所有收集器如下：

这里写图片描述

说明：图中存在连线表示可以搭配使用，总共有7种不同分代的收集器。

3.1 Serial 收集器

　　是最基本、历史最悠久的收集器。它是一个单线程的收集器。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到垃圾收集结束。官方说法： “Stop The World”。下图示意了 Serial 和 Serial Old的运行过程。

这里写图片描述

　　到目前为止，Serial 收集器依然是虚拟机运行在 Client 模式下的默认新生代收集器，优点在于：简单而高效，对于限定单个 CPU 的环境来说，Serial 收集器没有线程交互的开销，专心做垃圾收集自然能获得最高的单线程效率。

3.2 ParNew 收集器

　　ParNew 收集器是 Serial 收集器的多线程版本，Serial 收集器可用的控制参数、收集算法、Stop The World、对象分配规则、回收策略等都和 ParNew 一样。下图是 ParNew 的工作过程。

这里写图片描述

ParNew 是许多运行在 Server 模式下的首选新生代收集器，一个很重要的原因是：除了 Serial 外，目前只有它能与 CMS 收集器配合工作。它默认开启的收集线程数与 CPU 的数量相同。

3.3 Parallel Scavenge 收集器

　　新生代收集器，也是使用复制算法的收集器，又是多线程收集器。Parallel Scavenge 收集器的目标规则是达到一个可控制的吞吐量( Throughput )，经常被称作为 “吞吐量优先”收集器。主要适合在后台运算而不需要太多交互的任务。

3.4 Serial Old 收集器

　　是 Serial 收集器的老年代版本，是一个单线程收集器，使用 “标记—整理” 算法，主要给 Client 模式下的虚拟机使用。如果在 Scavenge 模式下，主要有两大用途：一种用途是在 JDK1.5 以及之前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

3.5 Parallel Old 收集器

　　是 Parallel Scavenge 收集器的老年代版本，使用多线程和 “标记—整理” 算法。下图为 Parallel Old 收集器的工作过程。JDK1.6 时开始提供。在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。下图为 Parallel Old 收集器的工作过程。

这里写图片描述

3.6 CMS 收集器

　　CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。是专门用来收集老年代的收集器。适合用在互联网站等重视服务的响应速度，希望系统停顿时间最短的场景中。 CMS 收集器是基于 “标记—清除” 算法实现的。整个运作过程分为 4 个步骤：

初始标记，标记GCRoots能直接关联到的对象，时间很短。
并发标记，进行GCRoots Tracing（可达性分析）过程，时间很长。
重新标记，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长。
并发清除，回收内存空间，时间很长。

其中，并发标记与并发清除两个阶段耗时最长，但是可以与用户线程并发执行。运行过程如下图所示

这里写图片描述

虽然 CMS 是一款优秀的收集器，但是也存在如下3个明显缺点：

CMS 收集器对 CPU 资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但会导致应用程序变慢，总吞吐量降低。CMS 默认启动的回收线程数是（CPU 数量 + 3）/ 4。当 CPU 不足 4 个时，CMS对用户程序的影响可能会变大，可能导致用户程序执行速度降低。
CMS 收集器无法处理浮动垃圾，可能出现 Concurrent Mode Failure 失败而导致另一次 Full GC 的产生。
由于是基于”标记—清除” 算法实现的，收集结束时会有大量空间碎片产生，会给大对象分配带来很大麻烦。往往会出现老年代还有很大空间剩余，但无法找到足够大的连续空间来分配对象而提前出发一次 Full GC。

3.7 G1 收集器

可以在新生代和老年代中只使用G1收集器。具有如下特点。

并行和并发。使用多个CPU来缩短Stop The World停顿时间，与用户线程并发执行。
分代收集。独立管理整个堆，但是能够采用不同的方式去处理新创建对象和已经存活了一段时间、熬过多次GC的旧对象，以获取更好的收集效果。
空间整合。基于标记 - 整理算法，不会产生内存空间碎片，收集后能提供规整的可用内存。
可预测的停顿。能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

使用 G1 收集器时，将整个 Java 堆划分为多个大小相等的独立区域（Region），新生代和老年代不是物理隔离的，它们都是一部分 Region（不需要连续）的集合。

G1收集器中，Region之间的对象引用以及其他收集器的新生代和老年代之间的对象引用，虚拟机都使用Remembered Set来避免全堆扫描的。每个Region对应一个Remembered Set,虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查老年代的对象是否引用了新生代的对象），如果是，则通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中，当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作可以分为如下几步

初始并发，标记GCRoots能直接关联到的对象；修改TAMS（Next Top At Mark Start）,使得下一阶段程序并发时，能够在可用的Region中创建新对象，需停顿线程，耗时很短。
并发标记，从GCRoots开始进行可达性分析，与用户程序并发执行，耗时很长。
最终标记，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，变动的记录将被记录在Remembered Set Logs中，此阶段会把其整合到Remembered Set中，需要停顿线程，与用户程序并行执行，耗时较短。
筛选回收，对各个Region的回收价值和成本进行排序，根据用户期望的GC时间进行回收，与用户程序并发执行，时间用户可控。

G1收集器具体的运行示意图如下

这里写图片描述

4. 内存分配与回收策略

对象主要分配在新生代的 Eden 区上，如果启动了本地线程分配缓冲，将按线程优先在 TLAB上分配，也有少数情况直接在老年代分配，分配的规则不是固定的，取决于当前使用的是哪一种垃圾收集器组合以及虚拟机的相关参数设置。

4.1 对象优先在 Eden 分配

对象通常在新生代的Eden区进行分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。

4.2 大对象直接进入老年代

需要大量连续内存空间的Java对象称为大对象，大对象的出现会导致提前触发垃圾收集以获取更大的连续的空间来进行大对象的分配。虚拟机提供了-XX:PretenureSizeThreadshold参数来设置大对象的阈值，超过阈值的对象直接分配到老年代。

4.3 长期存活的对象进入老年代

每个对象有一个对象年龄计数器，与前面的对象的存储布局中的GC分代年龄对应。对象出生在Eden区、经过一次Minor GC后仍然存活，并能够被Survivor容纳，设置年龄为1，对象在Survivor区每次经过一次Minor GC，年龄就加1，当年龄达到一定程度（默认15），就晋升到老年代，虚拟机提供了-XX:MaxTenuringThreshold来进行设置。

4.4 动态对象年龄判断

对象的年龄到达了 MaxTenuringThreshold 可以进入老年代，同时，如果在 survivor 区中相同年龄所有对象大小的总和大于 survivor 区的一半，年龄大于等于该年龄的对象就可以直接进入老年代。无需等到 MaxTenuringThreshold 中要求的年龄。

4.5 空间分配担保

在发生 Minor GC 时，虚拟机会检查老年代连续的空闲区域是否大于新生代所有对象的总和，若成立，则说明 Minor GC 是安全的，否则，虚拟机需要查看 HandlePromotionFailure 的值，看是否运行担保失败，若允许，则虚拟机继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，若大于，将尝试进行一次 Minor GC；若小于或者 HandlePromotionFailure 设置不运行冒险，那么此时将改成一次 Full GC，以上是 JDK 6 Update 24 之前的策略，之后的策略改变了，只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 Minor GC，否则将进行 Full GC。