java new 内存分配内存_jvm大局观之内存管理篇(二):当java中new一个对象,背后发生了什么...

前言

本篇是java内存区域管理系列教程之一 java创建对象的过程

全系列内容可在专栏中查阅jvm全局观​www.zhihu.com

今天我们谈谈 当java中new一个对象,背后发生了什么jvm全局观今天我们谈谈 当java中new一个对象,背后发生了什么

概括说来,就是 先后执行类加载,分配内存,初始化零值,设置对象头,初始化对象

看完本篇文章,读者将能够回答以下问题

1.当java中new一个对象,背后发生了什么

2.java内存分配中的指针碰撞和空闲列表分配是什么意思

3.多线程下对象的创建会存在什么问题笔墨不易,赠人玫瑰,手留余香

正文

我们以最常用的虚拟机HotSpot和最常用的内存区域Java堆为例，深入探讨一下HotSpot虚拟机在Java堆中对象分配全过程。

一. 新生对象所属类的加载检查

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

二. 为新生对象分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。

对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上便等同于把一块确定大小的内存块从Java堆中划分出来

优先在本地线程分配缓冲分配

除了如何划分可用空间外，在并发情况下划分不一定是线程安全的，有可能出现正在给A对象分配内存，指针还没有来得及修改，对象B又同时使用了原来的指针分配内存的情况，解决这个问题两种方案：分配内存空间的动作进行同步处理：实际上虚拟机采用CAS配上失败重试的方式保证了更新操作的原子性。

内存分配的动作按照线程划分在不同的空间中进行：为每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完 了，分配新的缓存区时才需要同步锁定,虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来设置注意: 在jdk8中UseTLAB是默认开启的

2.1 如何分配到一块空闲的内存

2.1.1 指针碰撞分配 。假设Java堆中内存是绝对规整的，所有被使用过的内存都被放在一 边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那 个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”(Bump The Pointer)。

2.1.2 空闲列表分配

但如果Java堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那 就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分 配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称 为“空闲列表”(Free List)

2.1.3 垃圾收集时是否带有空间压缩整理决定是上面两种分配方式中的一种

选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用 的垃圾收集器在收集时是否采用空间压缩整理(Compact)决定。 因此，当使用Serial、ParNew等带压缩整理过程的收集器时，系统采用的分配算法是指针碰撞，既简单又高效； 而当使用CMS这种基于清除(Sweep)算法的收集器时，理论上就只能采用较为复杂的空闲列表来分配内存。注意: 后面的系列文章中我们会知道,实际上堆中,又会依据存活的对象生命周期被划分为年轻代和老年代,不同的代有不同的回收机制,一般来说年轻代中都是带有空间压缩整理的垃圾收集,所以jvm中大部分堆中的对象分配既有指针碰撞(Bump The Pointer),又有空闲列表jvm大局观之内存管理篇(四):分代假说之下的java垃圾回收算法​zhuanlan.zhihu.com

三. 新生对象各属性初始化零值

内存分配完成之后，虚拟机必须将分配到的内存空间(但不包括对象头)都初始化为零值,这步操作保证了对象的实例字段 在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值

四. 设置新生对象的对象头

接下来，Java虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到 类的元数据信息、对象的哈希码(实际上对象的哈希码会延后到真正调用Object::hashCode()方法时才 计算)、对象的GC分代年龄等信息。这些信息存放在对象的对象头(Object Header)之中。

五. 为新生对象执行init方法

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。

但是从Java程序的视 角看来，对象创建才刚刚开始——构造函数，即Class文件中的()方法还没有执行，所有的字段都 为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。

一般来说new指令之后会接着执行 ()方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。发散: 当对象创建完成之后,指向这个对象的引用,一定是存储在栈区吗? 如果不是, 为什么? 如果有读者感兴趣,在评论区说明,我就在后续继续更新文章

扩展

扩展1:new对象过程案例:

Student类代码如下

public class Student {

private String name = "林青霞";

private int age = 27;

public Student() {

name = "刘意";

age = 30;

}

}

class StudentDemo {

public static void main(String[] args) {

Student s = new Student();

}

}

Student s = new Student()做了哪些事情?

1、把Student. class文件加载到内存

2、在栈内存给s变量开辟一个空间

3、在堆内存为学生对象申请一个空间

4、给成员变量进行默认初始化。null,0

5、给成员变量进行显示初始化。林青霞，27

6、通过构造方法给成员变量进行初始化。刘意，30

7、数据初始化完毕，然后把堆内存的地址值赋值给栈内存的s变量。

扩展2: 创建对象指令重排序问题:

new一个对象的简单分解动作分配对象的内存空间

初始化对象

设置引用指向分配的内存地址

其中2和3两步间会发生指令重排序，导致多线程时，如果在初始化之前访问对象，则会出现问题，单例模式的双重检测锁模式正是会存在这个问题。可以使用volatile来禁止指令重排序解决问题

先看如下代码：

public static Singleton getInstance(){

if(instance == null){

synchronized(Singleton.class){

if(instance==null)

instance = new Singleton();

}

}

return instance;

}

这个代码是一个Singleton的getInstance()方法，调用这个方法时，如果Singleton有实例，则返回实例，如果没有实例，调用构造函数(应为private的构造函数)new一个实例出来。这部分代码实现了在并发环境下的单例模式的功能。

这部分代码首先判断instance是否为null，如果确实为null，则进入一个synchronize包围的代码块，相当于上了锁，进入了临界区，为了防止在判断为null到进入临界区的过程中，有线程对其new了一个实例出来，再上锁完成之后，在对instance是否为null进行一次判断，如果这次还是为null，则可以确认确实instance为null，并且此时也不会有其他线程尝试new一个instance出来，因此可以放心地执行new对象的工作。

这个代码在单线程的环境下是没错的，但是如果在并发的环境下，会出现严重的问题。

问题其实出在java的编译器上，java的编译器会将字节码命令进行重排序以便进行优化，在第五行，构造函数的调用似乎应该在instance得到赋值之前发生，但是在java虚拟机内部，却不是这样的，完全有可能先new出来一个空的未调用过构造函数的instance对象，然后再将其赋值给instance引用，然后再调用构造函数，对instance对象当中的元素进行初始化。

这样，就很有可能，当instance被赋值一个空的实例对象的时候，另一个线程调用了getInstance()这个函数，另一个线程发现，instance并不是空的，于是愉快地return回了那个空的instance对象。这样，一个空的instance对象的引用就被流传到了其他线程当中，为非作歹。

为什么会出现部分构造的对象

简单来说是因为无序写入(out-of-order writes)。

如果构造函数写入非 final 字段，则不必立即将它们提交到内存，甚至可以在单例变量之后提交。构造函数其实已经完成，但这并不意味着所有写入对其它线程可见。

部分构造就是这种情况的一个糟糕体现，singleInstance 引用已对其它线程可见，但对象的内容singleInstance.getId() 对其它线程并不可见。就是因为对象构造过程中一系列指令写入内存的乱序，导致了失效对象的产生。

解决方法

在 Java 5.0 之后，使用 volatile 来修饰 singleInstance 实例，就不会产生指令重排序的情况，这样 DCL 也就可以正常工作了。

private volatile Singleton instance;

public static Singleton getInstance(){

if(instance == null){

synchronized(Singleton.class){

if(instance==null)

instance = new Singleton();

}

}

return instance;

}

但因为有了更加方便与安全的替代方式，DCL 也没有什么特别的优势，便被废弃了。

延迟初始化占位类模式

使用延迟初始化占位类模式，可以在保证延迟加载优点的同时，得到 Java 语言层面提供的安全保障。当然也包括 Java 内存模型相关，可以了解到更多 out-of-order writes 相关的原理。

也就是如下所示

public class ResouceFactory {

public static Resource resource= new Resource();

public static Resource getInstance() {

return resource;

}

}

因为在初始化器中采用了特殊的方式处理静态域，并提供了额外的线程安全性保证。静态初始化器是由JVM在类的初始化阶段执行，即在类被加载后并且被线程使用之前。由于JVM在初始化期间将获得一个锁，且每个线程都至少获取一次这个锁以确保这个类已经加载，故在静态初始化期间，内存写入操作将自动对所有的线程可见，以及避免数据破坏。

简言之，类中的静态变量在声明的时候就做初始化，可以经由JVM提供线程安全方便的保证，而无需自己添加synchronized关键字去进行同步，从而减少了线程同步带来的性能消耗。这种初始化方式被称为提前初始化。相对的，之前两种初始化方式，被称为惰性初始化或者延迟初始化。

考虑到有些类的实例在初始化的时候，可能会产生比较高的开销，故人们希望在需要用到的时候再进行初始化，于是结合延迟初始化域JVM初始化静态域的特点，产生了较为常用的延迟初始化占位类模式：

public class ResouceFactory {

private static class ResourceHolder {

public static Resource resource = new Resource();

}

public static Resource getInstance() {

return ResourceHolder.resource;

}

}

因为静态类在使用的时候才会被加载，故JVM第一次加载该静态类的时候，通过JVM即可实现静态域的线程同步，即满足了延迟加载的需求，也避开了同步带来的性能消耗。