【JVM专题】JVM对象创建与内存分配机制深度剖析

课程内容

一、JVM对象创建过程详解

创建对象的主要流程，基本如下图所示：

接下来我们分析一下各个阶段的含义。

类加载检查

虚拟机在遇到一条new指令的时候，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查其代表的类是否已经被加载、解析、初始化过了，如果没有则走第一节课提到的从类加载子系统LoadClass那一套。

*分配内存

对象所需内存的大小，其实在类的加载完成后就可以确定了，为对象分配内存，本质上就是从堆里面，找一块大小合适的地方，给对象使用，在这个过程中，需要解决两个问题。

1. 如何在堆上划分内存（采用怎样的策略）
2. 如何处理并发问题（多个线程抢占同一片空间）

接下来我们一个问题一个问题解决。

Q1：如何在堆上划分内存

我们常用的解决方案有2个，【指针碰撞】和【空闲列表】。

• 指针碰撞（Bump The Pointer）（默认）

如果Java堆中的内存是绝对规整的，所有用过的内存在一边，未使用过的内存放在另一边，那么在已使用内存跟空闲内存中间的交割点处的指针，即为指示器。后续分配内存，也仅仅只是把该指针向空闲内存方向移动对象大小的相等的距离，这就是指针碰撞。

• 空闲列表（Free List）

随着内存的使用、释放，往后内存中必然存在大量碎片，内存变得不规整，那肯定没办法继续进行指针碰撞了，为了解决这个问题，于是就出现了【空闲列表】。它由虚拟机维护一个列表，用来记录哪些内存块是可用的，方便在分配内存的时候，从列表中找到一块足够大的连续内存空间分配给对象实例。

Q2：如何处理并发问题

常用的解决方案，也有2个，分别是【CAS】和【TLAB】。

• CAS（Compare And Swap）

虚拟机采用【CAS+失败重试机制】保证更新操作的原子性，以此对分配内存空间的动作做同步处理

• TLAB（Thread Local Allocation Buffter，本地线程分配缓冲）（默认）

把内存分配的动作，以线程为单位分配在不同的空间中进行，即：每个线程在Java堆中预先分配一块小内存（线程私有，避免了并发竞争）。JVM通过-XX:+/-UseTLAB参数来设定是否需要使用TLAB，-XX:TLABSize指定TLAB大小。
细心的朋友们可能发现了，TLAB由虚拟机预分配大小，那这块大小是多少才比较合适呢？万一太小了，我的对象放不下怎么办？这个嘛，简单来说，根据策略以及GC方式的不同，会直接放到新生代的eden区，或者重新申请一块TLAB（事实上，TLAB也是在新生代eden区，TLAB只是侧重于独有的一块内存空间）。

实例化

老师的课上也叫这个阶段为“初始化”，但是在这里讲“初始化”会让大家跟后面的混淆，特别是在很多源码中的生命流程里也有初始化的概念，为了不跟后面的初始化混淆，这里还是严谨一点，叫做实例化吧。在这里，其实就是JVM给分配好内存的对象“赋0值”的过程。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值（这一步个人认为很有必要，相信大家都能理解实例化，但事实上很多人在CRUD过程中，完全忽略了该思想的精髓）

设置对象头

实例化完以后，虚拟机需要对对象进行必要的设置，例如：这个对象是属于那个类的实例（类型指针），对象的hashCode，对象的gc年龄等等信息。这些信息存放在对象的对象头Object Header里面。
总的来说，对象在内存中的布局可以分为三块区域：对象头（Header，一般不可见），实例数据（Instance Data，我们平时看到的数据），对齐填充（Padding，一般不可见）。

这里重点介绍下对象头，对象头的：

• 对象头，分三部分（前两部分必要，第三部分特殊）：
  • 第一部分，运行时数据，Mark Word。 包含：HashCode、GC年龄、锁状态标志、线程持有的锁、偏向线程id、偏向时间戳等
  • 第二部分，类型指针，KlassPointer。即：对象指向它的类元数据的指针，虚拟机就是通过这个指针来确定当前对象是谁的实例
  • 第三部分，长度，Length。它是数组对象特有的部分

下面是对象头的布局模型，以及普通对象跟数组对象的模型：


最后，这里再放一段示例代码，给大家展示一下对象的地址分布

public class JOLSample {

    public static void main(String[] args) {

        // 输出普通对象的对象头
        ClassLayout objectLayout = ClassLayout.parseInstance(new Object());
        System.out.println(objectLayout.toPrintable());

//        这里输出内容
//        java.lang.Object object internals:
//        OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
//        0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
//        4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
//        12     4        (loss due to the next object alignment)
//        Instance size: 16 bytes
//        Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

        // 输出数组对象的对象头
        ClassLayout arrayLayout = ClassLayout.parseInstance(new int[]{});
        System.out.println(arrayLayout.toPrintable());

//        这里输出内容
//        [I object internals:
//        OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
//        0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
//        4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        8     4        (object header)                           6d 01 00 f8 (01101101 00000001 00000000 11111000) (-134217363)
//        12     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        16     0    int [I.                             N/A
//        Instance size: 16 bytes
//        Space losses: 0 bytes internal + 0 bytes external = 0 bytes total


        // 输出复合对象的对象头
        ClassLayout complextLayout = ClassLayout.parseInstance(new A());
        System.out.println(complextLayout.toPrintable());

//        这里输出内容
//        org.tuling.jvm.jol.JOLSample$A object internals:
//        OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
//        0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
//        4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        8     4                    (object header)                           63 cc 00 f8 (01100011 11001100 00000000 11111000) (-134165405)
//        12     4                int A.id                                      0
//        16     1               byte A.b                                       0
//        17     3                    (alignment/padding gap)
//        20     4   java.lang.String A.name                                    null
//        24     4   java.lang.Object A.o                                       null
//        28     4                    (loss due to the next object alignment)
//        Instance size: 32 bytes
//        Space losses: 3 bytes internal + 4 bytes external = 7 bytes total
    }

    public static class A {
        // { // 这里其实有一个隐藏的对象头
        //     mark word, // 8B 对象头比埃及字段
        //     klass pointer, // 4B 对象头的类型指针，指向方法区的类元信息
        // }
        int id; // 4B
        String name; // 4B 如果关闭了指针压缩 -XX:-UseCompressedOops，则占用8B
        byte b; // 1B
        Object o; // 4B 如果关闭了指针压缩 -XX:-UseCompressedOops，则占用8B
    }
}

执行方法

执行方法，即对象将按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法

二、指针压缩详解

在讲指针压缩的细节之前，需要知道两个问题。何为指针压缩？为什么要进行指针压缩？
第一个问题，指针压缩就是字面意思。但是我们需要知道，这里提到的指针是哪些。他们一般是：对象头里面的Klass Pointer，以及成员变量里面的对象引用。
第二个问题，为什么要进行指针压缩呢？在说标准答案之前，我先引导一下大家小小认识一下”运行内存-RAM“的概念。

1. 32位机器，最大的寻址空间是多少，2^32=1024 * 1024 * 1024 * 4 = 4G。这就是为什么我们组装电脑的时候，通常建议Ram=4G的玩家装32位系统；8G及以上的推荐装64位系统
2. 64位机器，最大寻址空间是多少？2^64=好多好多G。显然，我们平时用的8G，16G，32G，在64位系统下寻址空间显得绰绰有余。算下来，我们的高32位中，至少有29位（32G RAM）是不需要用到的。

到了这里估计大家应该理解为何要指针压缩了吧，说一下标准答案吧。

1. 在64位平台的HotSpot中使用32位指针，内存使用会多出1.5倍左右，使用较大指针在主内存和缓存之间移动数据，占用较大宽带，同时GC也会承受较大压力
2. 为了减少64位平台下内存的消耗，启用指针压缩功能
3. 在jvm中，32位地址最大支持4G内存(2的32次方)，可以通过对对象指针的压缩编码、解码方式进行优化，使得jvm只用32位地址就可以支持更大的内存配置(小于等于32G)
4. 堆内存小于4G时，不需要启用指针压缩，jvm会直接去除高32位地址，即使用低虚拟地址空间
5. 堆内存大于32G时，压缩指针会失效，会强制使用64位(即8字节)来对java对象寻址，这就会出现1的问题，所以堆内存不要大于32G为好

【拓展】Q1：为什么不要大于32G，为什么会失效？
答：由于Java对象存在【对齐填充】，使得Java对象的大小，恒为8字节的整数倍数。这样有什么意义呢？8的倍数有哪些，8，16，24，32… 转换成2进制你会发现，他们的低3位恒等于【000】。既然低3位恒等于这个，那我32位里面真实有效的数字不就是29位了吗？但是这显然有点浪费，所以，我们可以通过【右移】3位获得原32位后的33、34、35补足32位（反正不用白不用），这就是【指针压缩】的奥妙。2的35次方是多少？正好是32G

最后，这里放一段上面的示例代码中，A对象的在开启跟关闭指针压缩前后对象大小的变化：

//        开启指针压缩
//        org.tuling.jvm.jol.JOLSample$A object internals:
//        OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
//        0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
//        4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        8     4                    (object header)                           63 cc 00 f8 (01100011 11001100 00000000 11111000) (-134165405)
//        12     4                int A.id                                      0
//        16     1               byte A.b                                       0
//        17     3                    (alignment/padding gap)
//        20     4   java.lang.String A.name                                    null
//        24     4   java.lang.Object A.o                                       null
//        28     4                    (loss due to the next object alignment)
//        Instance size: 32 bytes
//        Space losses: 3 bytes internal + 4 bytes external = 7 bytes total
//-------------------------------------------------------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------------------------------------------------------
//        没开启指针压缩
//        org.tuling.jvm.jol.JOLSample$A object internals:
//        OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
//        0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
//        4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        8     4                    (object header)                           d8 35 9a 1d (11011000 00110101 10011010 00011101) (496645592)
//        12     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
//        16     4                int A.id                                      0
//        20     1               byte A.b                                       0
//        21     3                    (alignment/padding gap)
//        24     8   java.lang.String A.name                                    null
//        32     8   java.lang.Object A.o                                       null
//        Instance size: 40 bytes
//        Space losses: 3 bytes internal + 0 bytes external = 3 bytes total

上面最最明显的一点就是：开启之前，A对象的String name跟Object o只占用4字节，但是关闭之后，就占用8字节了

三、*JVM对象内存分配详解

这里算是重中之重了。从上节课中，我们知道，MinorGC是发生在年轻代的，一般回收速度比较快，发生的频率比较频繁；FullGC是发生在老年代的，回收的是整一片JVM运行时数据区，它耗费的时间一般是MinorGC的10倍以上。很显然，FullGC比MinorGC复杂的多，STW的时间也长的多！所以，如何避免频繁的FullGC是我们值得深究的话题。
既然我们知道FullGC是因为老年代满了才触发的GC，那么，只要探究老年代的内存是如何来的，我们就可以下手了。先来一张对象内存分配流程图，如下

对象内存分配流程图

从上图中，我们可以看到，进入老年代的对象，有三种，这就是我们下面想要给大家介绍的概念。

大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。
比如设置JVM参数：-XX:PretenureSizeThreshold=1000000 (单位是字节) -XX:+UseSerialGC ，大于10M的对象则会直接进入老年代。
为什么要这么设置呢？因为，每次垃圾收集的时候，是没办法预测年轻代中的这些对象哪些、多少能进入老年代的，相当于是一个黑盒。而我们知道，这些对象如果不直接放进老年代，也许会（谁知道是不是存活对象？）在未来的MinorGC中不断的在s1-s2之间来回横跳。然而MinorGC采用的是复制算法，如果有诸多大对象来回横跳其实是很拉性能的，所以为了效率，干脆让他们进入老年代吧。

长期存活对象进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在
老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor
空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度
（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中。对象晋升到老年代
的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

符合动态年龄判断的对象进入老年代

当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的
50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，
例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会
把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年
龄判断机制一般是在minor gc之后触发的。

老年代空间分配担保机制

最后，我们这里还要提到一个概念，老年代空间分配担保机制，他的过程是这样的。
年轻代每次MinorGC之前JVM都会计算下老年代剩余可用空间，如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)，就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了。如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次MinorGC后进入老年代的对象的平均大小。如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次FullGC，对老年代和年轻代一起回收一次垃圾，如果回收完还是没有足够空间存放新的对象就会发生"OOM"！当然，如果MinorGC之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，FullGC完之后如果还是没有空间放MinorGC之后的存活对象，则也会发生“OOM”

四、逃逸分析&栈上分配&标量替换详解

在前面的学习中我们知道，通常我们分配对象，都是在堆上操作的。当对象不可用之后，需要依靠GC（垃圾回收）进行内存回收。但由于GC过程中，存在不可避免地STW机制，甚至GC的发展路程中，可以说都是围绕着STW机制做优化的。既然如此，我们怎样才能避免更频繁的GC呢？
JVM想到了通过逃逸分析确定该对象会不会被外部访问，接着通过在栈上分配内存的方式，减少对象进入堆中。这样，随着对象所占用的栈帧出栈而销毁，进而减轻了GC压力！（但据说，在实际生产中，能符合逃逸分析的其实并不多，哈哈哈）

• 对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如return局部对象。

public User test1() {
	User user = new User();
	user.setId(1);
	user.setName("返回");
	return user;
}

public User test1() {
	User user = new User();
	user.setId(1);
	user.setName("局部使用");
}

很显然test1方法中的user对象被返回了，这个对象的作用域范围不确定，test2方法中的user对象我们可以确定当方法结束这个对象就可以认为是无效对象了，对于这样的对象我们其实可以将其分配在栈内存里，让其在方法束时跟随栈内存一起被回收掉。
JVM对于这种情况可以通过开启逃逸分析参数(-XX:+DoEscapeAnalysis)来优化对象内存分配位置，使其通过标量替换优先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，如果要关闭使用参数(-XX:-DoEscapeAnalysis)

• 标量替换：在通过逃逸分析确定该对象不会被外部引用之后，并且确定该对象可以进一步分解时，则JVM不会创建该对象。而是，将该对象的成员变量分解成若干个，被引用方法使用的局部变量所代替，这些代替的局部变量在栈帧或者寄存器上分配空间，这样就不会因为没有一块足够大的连续内存空间，导致对象内存不够分配了。开启标量替换参数(-XX:+EliminateAllocations)，JDK7之后默认开启
  • 标量与聚合量：标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一步分解的聚合量。

五、对象内存回收机制详解

堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对
象）。如何判断呢？这里我们先说两种（后续还有其他算法）。其一是引用计数法，但是意义已经不大了，因为它无法解决循环依赖的BUG。第二种是可达性分析算法，这里重点介绍下。

• 可达性分析法。将“GC Roots” 对象作为起点，从这些节点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的对象都是垃圾对象。

GC Roots根节点：线程栈的本地变量、静态变量、本地方法栈的变量等等。或者严格来说，GCRoot通常为以下对象：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等
• 方法区中类静态属性引用的对象。例如java类的引用类型静态变量
• 方法区中常量引用的对象。例如字符串常量池里的引用
• 本地方法栈中 JNI 引用的对象
• 被同步锁持有的对象
• Java 虚拟机内部的引用。如基本数据类型对应的class对象，一些常驻的异常对象等，还有类加载器
  

六、如何判断一个对象是否存活

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一
个对象死亡，至少要经历再次标记过程。
标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链

1. 第一次标记并进行一次筛选
   筛选的条件是此对象是否有必要执行finalize()方法
   当对象没有覆盖finalize方法，对象将直接被回收
2. 第二次标记
   如果这个对象覆盖了finalize方法，finalize方法是对象脱逃死亡命运的最后一次机会，如果对象要在finalize()中成功拯救
   自己，只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第
   二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了
   注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次

七、如何判断一个类是无用的类

方法区主要回收的是无用的类，那么如何判断一个类是无用的类的呢？类需要同时满足下面3个条件才能算是 “无用的类” ：

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

学习总结

1. 学习了对象的内存模型。对象在内存中的布局可以分为3个区域：对象头，实例数据，对齐填充
2. 对象头，又包含了3个部分，分别是：Mark Word标记字段，64位系统下占8个字节；Klass Pointer类型指针，64位系统下占8个字节；最后一个比较特殊，Length数组长度，只有数组对象才有这个，占4个字节
3. 对象头中的Mark Word标记字段，存放的是对象的HashCode，GC年龄，锁状态，线程持有锁的标志（00-轻量级锁；10-重量级锁；11-GC中；01-无锁/偏向锁，需要结合锁标志位）、偏向线程id、偏向发生时间戳
4. 学习了内存分配的流程，理解了三个引发对象进入老年代的机制。分别是：大对象机制、动态年龄判断机制、长时间存活对象机制
5. 学习了逃逸分析，栈上分配以及标量替换的一种内存分配机制