转载

深入探究JVM之对象创建及分配策略

前言

Java是面向对象的语言，所谓“万事万物皆对象”就是Java是基于对象来设计程序的，没有对象程序就无法运行（8大基本类型除外），那么对象是如何创建的？在内存中又是怎么分配的呢？

正文

一、对象的创建方式

在Java中我们有几种方式可以创建一个新的对象呢？总共有以下几种方式：

new关键字
反射
clone
反序列化
Unsafe.allocateInstance

为了便于说明和理解，下文仅针对new出来的对象进行讨论。

二、对象的创建过程

Java中对象的创建过程就包含上图中的5个步骤，首先需要验证待创建对象的类是否已经被JVM记载，如果没有则会先进行类的加载，如果已经加载则会在堆中（不完全是堆，后文会讲到）分配内存；分配完内存后则是对对象的成员变量设置初始值（0或null），这样对象在堆中就创建好了。但是，这个对象是属于哪个类的还不知道，因为类信息存在于方法区，所以还需要设置对象的头部（当然头部中也不仅仅只有类型指针信息，稍后也会详细讲到），这样堆中才创建好了一个 完整的对象 ，但是这个对象的成员变量还都是初始值，所以最后会调用init方法按照我们自己的意愿初始化对象，一个 真正的对象 就创建好了。

对象的整个创建过程是非常简单的，但是其中还有很多细节，比如对象会在哪里创建？分配内存有哪些方式？怎么保证线程安全？对象头中有哪些信息？下面一一讲解。

对象在哪里创建

基本上所有的对象都是在堆中，但并非绝对，在JDK1.6版本引入了 逃逸分析 技术。逃逸分析就是指针对对象的作用域进行判定，当一个对象在方法中被定义后，如果被 其它方法 或 其它线程 访问到，就称为 方法逃逸 或 线程逃逸 。

该技术针对 未逃逸的对象 做了一个优化： 栈上分配 （除此之外还有 同步消除 、 标量替换 ，这里暂时不讲）。这个优化是指当一个对象能被确定不会在该方法之外被引用，那么就可以直接在虚拟机栈中创建该对象，那么这个对象就可以随着线程的消亡而销毁，不再需要垃圾回收器进行回收。这个优化带来的收益是明显的，因为有相当一部分对象都只会在该方法内部被引用。 逃逸分析 默认是开启的，可以通过-XX:-DoEscapeAnalysis参数关闭。下面看一个实例：

public class EscapeAnalysisTest {
    public static void main(String[] args) throws Exception {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 50000000; i++) {//5000万次---5000万个对象
            allocate();
        }
        System.out.println((System.currentTimeMillis() - start) + " ms");
        Thread.sleep(600000);
    }

    static void allocate() {//逃逸分析（不会逃逸出方法）
        //这个myObject引用没有出去，也没有其他方法使用
        MyObject myObject = new MyObject(2020, 2020.6);
    }

    static class MyObject {
        int a;
        double b;

        MyObject(int a, double b) {
            this.a = a;
            this.b = b;
        }
    }
}

加上-XX:+PrintGC参数运行上面的方法，会看到控制台只是打印了执行时间5ms，但是若再加上-XX:-DoEscapeAnalysis关闭逃逸分析就会出现下面的结果：

[GC (Allocation Failure)  66384K->848K(251392K), 0.0012528 secs]
[GC (Allocation Failure)  66384K->816K(251392K), 0.0010461 secs]
[GC (Allocation Failure)  66352K->848K(316928K), 0.0009666 secs]
[GC (Allocation Failure)  131920K->784K(316928K), 0.0018284 secs]
[GC (Allocation Failure)  131856K->816K(438272K), 0.0009315 secs]
[GC (Allocation Failure)  262960K->684K(438272K), 0.0022738 secs]
[GC (Allocation Failure)  262828K->684K(700928K), 0.0005052 secs]
308 ms

执行时间大大提升，主要是用在了GC回收上。

分配内存

分配方式
JVM有两种分配内存的方式： 指针碰撞 和 空闲列表 。使用哪种方式取决于堆中内存 是否规整 ，而 是否规整 又取决于使用的 垃圾回收器 ，这个是下一篇的内容。如果内存规整，那么就会使用 指针碰撞 分配内存，也就是将已用的内存和未用的内存分开分别放到一边，中间使用指针作为 分界线 ；当需要分配内存时，指针就向未分配的那一边挪动一段与对象大小相等的距离。如果内存不是规整的，JVM会维护一个列表，列表中会记录哪些内存是可用的，分配内存时首先就会去这个表里面找到可用且大小合适的内存。
线程安全
理解了上面的两种方式，敏锐的读者应该很快就能发现其中的问题，我们的JVM肯定不会以单线程的方式去堆中创建对象，那样效率是极低的，那么怎么保证同一时间不会有两个线程同时占用同一块内存呢？JVM同样有两种方式保证线程安全：CAS和TLAB（本地线程缓冲）。
- CAS是compare and swap，涉及到 预期值 、 内存值 和 更新值 。意思当前线程每当需要分配内存时首先从内存中取出值和期望值比较，如果相等则将内存中的值更新为 更新值 ，否则则继续循环比较，这样当前线程在申请内存时，一旦该内存被其它线程提前占据，那么当前线程就会去申请其它未被占据的内存，
- TLAB是指线程首先会去堆中申请一块内存，每个线程都在各自占据的内存中创建对象，也就不存在线程安全问题了。可以通过-XX:+/-UseTLAB参数进行控制。

对象的内存布局

在HotSpot虚拟机中，对象在内存中分为三块：对象头、实例数据和对齐填充。如下图：

对象的内存布局上面这张图写的很清楚了，其中 自身运行时数据 了解一下有哪些信息即可，类型指针则是指向对象所属的类，如果对象是数组，则对象头中还会包含数组的长度信息；实例数据就是指对象的字段信息；最后对齐填充则不是必须的，因为为了方便处理和计算，HotSpot要求对象的大小必须是8字节的整数倍，因此当不满8字节的整数倍时，就需要对齐填充来补全。

三、对象的访问定位

当对象创建完成后就存在于堆中，那么栈中怎么定位并引用到该对象呢？虚拟机规范中本身并没有定义这一部分该如何实现，具体的实现取决于各个虚拟机厂商，而目前主流的定位方式有两种：句柄和 直接指针 。

句柄
通过句柄的方式引用就是虚拟机首先会在堆中划分一块区域作为句柄池，句柄池中包含了指向 对象实例 和 类型数据 的指针，而栈中则只需要引用句柄池即可。这种方式的好处显而易见，引用非常稳定，不会随着对象的移动而需要改变栈中的引用，但这样势必会降低引用的性能，同时堆中可用内存变少。
直接指针
顾名思义，直接指针就是指栈中引用直接指向堆中的对象，这样做的好处就是效率非常高，不需要通过句柄池中转，但也因此失去了稳定性。

以上两种方式在各个语言和框架都有使用，而本文所讨论的HotSpot虚拟机使用的是 直接指针 方式，因为对象的访问是非常频繁的，这时效率就显得格外重要。

四、判断对象的存活

对象生死

JVM不需要我们手动释放内存，这是Java广受欢迎的原因之一，那么它是如何做到自动管理内存，回收不需要的对象的呢？既然要回收对象，那么就需要判断哪些对象是可以被回收的，即对象的死活判定，哪些对象不会再被引用？有两种实现方式： 引用计数法 和 可达性分析 。

引用计数法：这个算法很简单，每个对象关联一个计数器，对象每被引用一次，计数器就加1，引用失效时，计数器就减一，垃圾回收时只需要回收计数为0的对象即可。这样做效率很高，但是这个算法有个显著的缺点，没法解决循环依赖，即A依赖B，B依赖A，这样它们的计数器都为1，但实际上除此之外没有任何地方引用它们了，就会导致 内存泄露 （即内存无法被释放）。
可达性分析：相较于引用计数法，这个算法效率会低一些，但却是虚拟机采用的方式，因为它就能解决循环依赖的问题。该算法会将一部分对象作为 GC Roots ，然后以这些对象作为起点开始搜索，当一个对象到 GC Roots 没有任何途径可以到达时，则表示该对象可以被回收。问题就在于那些对象可以作为 GC Roots 呢？
- 虚拟机栈（栈帧中的局部变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 常量池引用的对象
- 本地方法栈中JNI（native方法）引用的对象

以上4种非常好理解，是重点，需要熟记于心，因为上面4种对象是在方法运行时或常量引用的对象，在对应的生命周期是肯定不能被GC回收的，作为 GC Roots 自然再合适不过。另外还有下面几种可以作为了解：

JVM内部引用的对象（class对象、异常对象、类加载器等）
被同步锁（synchronized关键字）持有的对象
JVM内部的JMXBean、JVMTI中注册的回调、本地代码缓存等
JVM中实现的“临时性”对象，跨代引用的对象

回收方法区

除了堆中对象需要回收，方法区中的class对象也是可以被回收的，但是回收的条件非常苛刻：

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

可以看到方法区的回收条件是多么苛刻，所以方法区的回收率一般极低，因此可以通过-Xnoclassgc关闭方法区的回收，提升GC效率，但需要注意，关闭后将会导致方法区的内存永久被占用，导致OOM出现。

引用

通过上文我们可以发现，对象的存活判定都是基于引用，而Java中引用又分为了4种：

强引用：平时我们使用=赋值就属于强引用，被强引用关联的对象，永远不会被GC回收。
软引用（SoftReference）：常用来引用一些 有用但并非必需 的对象，如实现缓存。因为软引用只会在要发生OOM之前检查并被回收掉，如果回收后空间仍然不足，才会抛出OOM异常。
弱引用（WeakReference）：比软引用更弱的引用，只要发生垃圾回收就会被回收掉的引用，也可以用来实现缓存。在Java中，WeakHashMap和ThreadLocal的键都是利用弱引用实现的（注意这两个类的区别，前者可以配合ReferenceQueue使用，当key被回收时会被加入到该队列中，继而在清除null key时直接扫描这个队列即可；而后者在清除null key时需要遍历所有的键。关于ThreaLocal后面会在并发系列中详细分析）。
虚引用（PhantomReference）：最弱的引用，一个对象是否有虚引用，完全不会影响到其生命周期，无法通过该引用获取到一个对象的实例，使用时需要和 ReferenceQueue 配合使用，而使用它的唯一目的就是在这个对象被垃圾回收时能够接收到一个通知。

对象的自我拯救

虚拟机提供了一次自我拯救的机会给对象，即finalize方法。如果对象覆盖了该方法，当经过 可达性分析 后，就会进行一次判断，判断该对象是否有必要执行finalize方法，如果 对象没有覆盖该方法 或者 已经执行过一次该方法 都会判定为该对象没有必要执行finalize方法，在GC时被回收。否则就会将该对象放入到一个叫F-Queue的队列中，之后GC会对该队列的对象进行 二次标记 ，即调用该方法，如果我们要让该对象复活，那么就只需要在finalize方法中将该对象重新与 GC Roots 关联上即可。

该方法是虚拟机提供给对象复活的唯一机会，但是该方法作用极小，因为使用不慎可能会导致系统崩溃，另外由于它的运行优先级也非常低，常常需要主线程等待它的执行，导致系统性能大大降低，所以基本上可以忘记该方法的存在了。

五、对象的分配策略

上文说到对象是在堆中分配内存的，但是堆中也是分为 新生代 和 老年代 的，新生代中又分了 Eden 、 from 、 survivor 区，那么对象具体会分配到哪个区呢？这涉及到对象的分配规则，下面一一说明。

优先在Eden区分配

大多数情况，对象直接在Eden区中分配内存，当Eden区内存不足时，就会进行一次MinorGC（新生代垃圾回收，可以通过-XX:+PrintGCDetails这个参数打印GC日志信息）。

大对象直接进入老年代

什么是大对象？虚拟机提供了一个参数：-XX:PretenureSizeThreshold，当对象大小大于该值时，该对象就会直接被分配到老年代中（该参数只对Serial和ParNew垃圾收集器有效）。为什么不分配到新生代中呢？因为在新生代中每一次MinroGC都会导致对象在Eden、from和sruvivor中复制，如果存在很多这样的大对象，那么新生代的GC和复制效率就会极低（关于垃GC的内容后面的文章会详细讲解）。

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

既然对象优先在新生代中分配，那么什么时候会进入到老年代呢？这就和上文讲解的对象头中的分代年龄有关了，默认情况下超过15岁就会进入老年代，可以通过-XX:MaxTenuringThreshold参数进行设置。那岁数又是怎么增长的呢？每当对象熬过一次MiniorGC后年龄都会增加1岁。

动态对象年龄判定

但是虚拟机并不是要求对象年龄必须达到 MaxTenuringThreshold 才能晋升老年代，当 Survivor空间中相同年龄的所有对象的大小总和大于Survivor空间一半时，年龄大于或等于该年龄的对象就会直接晋升到老年代。

空间分配担保

在发生MiniorGC之前，虚拟机首先会检查老年代中最大可用的连续空间是否大于新生代所有对象的总和，如果大于则进行一次MiniorGC；否则，则会检查 HandlePromotionFailure 设置值是否允许担保失败。如果允许则会检查老年代最大连续空间是否大于历次晋升到老年代对象的平均大小，如果大于则进行一次MiniorGC，否则则进行一次FullGC。

为什么要这么设计呢？因为频繁的FullGC会导致性能大大降低，而取 历次晋升老年代对象的平均大小 肯定也不是百分百有效，因为存在对象突然大大增加的情况，这个时候就会出现担保失败的情况，也会导致FullGC。需要注意的是 HandlePromotionFailure 这个参数在JDK6Update24后就不会再影响到虚拟机的空间分配担保策略了，即默认老年代的连续空间大于新生代对象的总大小或历次晋升的平均大小就会进行MinorGC，否则进行FullGC。