死磕JVM（五）对象的创建

死磕JVM（一）内存区域 https://blog.csdn.net/u012133048/article/details/85344025

死磕JVM（二）内存模型 https://blog.csdn.net/u012133048/article/details/87886352

死磕JVM（三）内存溢出 https://blog.csdn.net/u012133048/article/details/87891398

死磕JVM（四） 垃圾回收机制 https://blog.csdn.net/u012133048/article/details/85413539

死磕JVM（五）对象的创建 https://blog.csdn.net/u012133048/article/details/87938452

死磕JVM（六） 类加载机制 https://blog.csdn.net/u012133048/article/details/85378148

死磕JVM (七) 锁优化 https://blog.csdn.net/u012133048/article/details/85490843

死磕JVM (八) 总结 https://blog.csdn.net/u012133048/article/details/88069289

对象的创建

整体流程

1 检查引用

虚拟机遇到new指令时，首先去检查这个指令的参数能否在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过，如果没有，必须执行类加载的过程。

2 分配内存空间

2.1空间分配方案

加载后，虚拟机将对新对象分配内存，所需的内存大小在类加载完成后便完全可知。为对象分配空间有两种方式：

1. 指针碰撞：适用于内存空间相对规整，用过的在一边，没用过的在另一边，中间放着指针作为分界点的指示器，所谓的分配内存，就是将指针往内存空间空闲的部分移动。

2. 空闲列表：内存空间不规整的情况下，虚拟机需要维护一个空间列表，在表中记录哪块内存是可用的。

综上所述，结合java堆中新生代结构，以及新生代的垃圾回收算法一般给予复制算法，内存空间相对规整，因此新生代垃圾收集器在（serail和ParNew）垃圾回收过程系中统采用分配算法是指针碰撞，而在老年代，采用CMS等基于标记清除算法的垃圾收集器，则采用的是空闲列表。

2.2 解决在创建对象时内存空间冲突的问题

因为在虚拟机创建内存的操作十分频繁，在并发情况下，对A对象分配内存后，指针还未修改，对象B又使用了原来的指针分配内存。有两种方法解决上述问题：

1. 虚拟机采用CAS 配上失败重试的方式保证操作的原子性
2. 内存分配动作根据线程分配在不同空间中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程缓冲（TLAB，TLAB在Eden区中），哪个线程需要分配，就在哪个线程的TLAB分配，只有当TLAB用完需要分配新的TLAB时，才需要加同步锁。TLAB可以通过-XX:+/- UseTLAB参数来设置。

3 内存分配完成后需要初始化值

虚拟机需要将分配的内存空间都初始化为零值（不包括对象头），如果使用TLAB，则该过程在TLAB中进行。这一步保证了对象的实例字段在java代码中不赋予初值就可以直接使用。
这里说明了一个问题，这里分配内存是为类字段的实例来分配的。也只有类字段才可以不赋予初值直接使用，局部变量的字段必须赋予初值。

4 虚拟机需要对对象内存进行设置

对象在内存中分为3块区域：对象头、实例数据、和对齐填充。
这个对象属于哪个类，如何才能找到类的元数据信息，对象的哈希码，GC分代年龄等。这些信息都存放在对象头中。

4.1 对象头

对象头包括两部分(数组的情况下包含3部分)信息：

1. Mark Word：对象自身运行时数据包括哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向锁ID、偏向时间戳，这部分数据长度在32位和64位虚拟机中长度分别为32bit和64bit（4字节和8字节，一个字节8bit）。
   对象存储的运行时数据很多时，会超过32和64位，为了增加对象头的空间使用效率，Mark Word被设计成为一个非固定的数据结构，以便在极小的空间内存储尽量多的信息，它会根据自己的状态复用自己的存储空间；

2. 类型指针：第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例（这部分并不是必须的，通过句柄来定位对象时，在句柄池中保存类元数据指针，而不是对象本身）；

3. 如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据。因为虚拟机可以通过普通 Java对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。

例如，在 32 位的 HotSpot 虚拟机中，如果对象处于未被锁定的状态下，那么 Mark Word 的 32bit 空间中的 25bit 用于存储对象哈希码，4bit 用于存储对象分代年龄，2bit 用于存储锁标志位，1bit 固定为 0，如下表所示：

在 32 位系统下，存放 Class 指针的空间大小是 4 字节，Mark Word 空间大小也是4字节，因此头部就是 8 字节，如果是数组就需要再加 4 字节表示数组的长度，如下表所示：

4.2 实例数据

实例数据部分是对象真正存储的有效信息，也既是我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的都需要记录下来。
这部分的存储顺序会受到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺序的影响。

4.3 对齐填充

对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。对象头正好是8字节的倍数（1倍或者2倍），因此当对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

一个【估算对象大小】的小例子from https://www.cnblogs.com/zhengbin/p/6490953.html#_label5。
32 位系统下：
当使用 new Object() 时，JVM 将会分配 8（Mark Word+类型指针） 字节的空间，也就是128 个 Object 对象将占用 1KB 的空间。
当使用 new Integer()，那么对象里还有一个 int 值，其占用 4 字节，这个对象也就是 8+4=12 字节，对齐后，该对象就是 16 字节。
以上只是一些简单的对象，那么对象的内部属性是怎么排布的？

Class A {
    int i;
    byte b;
    String str;
}

其中对象头部占用8 字节；byte 8 位长，占用 1 字节；int 32 位长，占用 4 字节；String 只有引用，占用 4 字节；那么对象 A 一共占用了 8+1+4+4=17 字节，按照 8 字节对齐原则，对象大小也就是 24 字节。

这个计算看起来是没有问题的，对象的大小也确实是 24 字节，但是对齐（padding）的位置并不是全是在最后：在 HotSpot VM 中，对象排布时，间隙是在 4 字节基础上的（在 32 位和 64 位压缩模式下）。上述例子中，int 后面的 byte，空隙只剩下 3 字节，接下来的 String 对象引用需要 4 字节来存放，因此 byte 和对象引用之间就会有 3 字节对齐，对象引用排布后，最后会有 4 字节对齐，因此结果上依然是 7 字节对齐。此时对象的结构示意图，如下图所示：

5 执行赋值

执行init过程，，也就是执行类构造函数的过程，为对象中的变量赋值。（这部分的过程还需要再学习）

6 访问对象

建立对象是为了使用对象，在程序中需要通过栈上的reference(引用)数据来操作堆上的具体对象。目前通过引用去定位和方位堆中的对象有两种方式：

1. 使用句柄：在java堆中会划分一块内存作为句柄池，栈中的引用中存储的就是对象在句柄池中的地址，句柄池中包含了对象实例数据与类型数据的地址。使用句柄：在java堆中会划分一块内存作为句柄池，栈中的引用中存储的就是对象在句柄池中的地址，句柄池中包含了对象实例数据与类型数据的地址。
2. 直接使用指针访问：java堆中的对象数据中需要包含着对象类型数据的指针。

两种方法都要自己的特点。

方法	特点
句柄	对象被移动时，只需修改句柄的地址，无需修改reference本身
直接指针	访问速度快，节省了一次指针定位的开销

以上都是个人学习成果，盗用了网上一些大神的图，要是哪里理解的有问题，欢迎指正。