【JVM系列4】new Object()到底占用几个字节,看完这篇就完全明白了

前言

上一篇咱们分析了Java虚拟机方法执行流程及方法重载和方法重写原理,并分析了方法的调用过程及原理,Java虚拟机栈是线程私有的,没有数据安全问题,而堆相比较于Java虚拟机栈而言更为复杂,由于堆是全部线程共享的一块内存空间,会出现线程安全性问题,而垃圾回收也主要是回收堆内空间,因此堆内的布局咱们很是有必要深刻去了解一下。如今就让咱们继续来分析一下堆内布局以及Java对象在内存中的布局把。java

对象的指向

先来看一段代码:面试

`package com.zwx.jvm;

public class HeapMemory {
    private Object obj1 = new Object();

    public static void main(String[] args) {
        Object obj2 = new Object();
    }
}`

上面的代码中,obj1 和obj2在内存中有什么区别?算法

咱们先来回忆一下JVM系列1的文章中有提到,方法区存储每一个类的结构,好比:运行时常量池、属性和方法数据,以及方法和构造函数等数据。因此咱们这个obj1是存在方法区的,而new会建立一个对象实例,对象实例是存储在堆内的,因而就有了下面这幅图(方法区指向堆):
在这里插入图片描述
而obj2 是属于方法内的局部变量,存储在Java虚拟机栈内的栈帧中的局部变量表内,这就是经典的栈指向堆
在这里插入图片描述
这里咱们再来思考一下,咱们一个变量指向了堆,而堆内只是存储了一个实例对象,那么堆内的示例对象是如何知道本身属于哪一个Class,也就是说这个实例是如何知道本身所对应的类元信息的呢?这就涉及到了一个Java对象在内存中是如何布局的。安全

Java内存模型

对象内存中能够分为三块区域:对象头(Header),实例数据(Instance Data)和对齐填充(Padding),以64位操做系统为例(未开启指针压缩的状况) Java对象布局以下图所示:
在这里插入图片描述
其中对象头中的Mark Word中的详细信息在文章synchronized锁升级原理中有详细介绍。
上图中的对齐填充不是必定有的,若是对象头和实例数据加起来恰好是8字节的倍数,那么就不须要对齐填充。jvm

知道了Java内存布局,那么咱们来看一个面试问题函数

Object obj=new Object()占用字节

这是网上不少人都会提到的一个问题,那么结合上面的Java内存布局,咱们来分析下,以64位操做系统为例,new Object()占用大小分为两种状况:布局

  • 未开启指针压缩
    占用大小为:8(Mark Word)+8(Class Pointer)=16字节
  • 开启了指针压缩(默认是开启的)
    开启指针压缩后,Class Pointer会被压缩为4字节,最终大小为:
    8(Mark Word)+4(Class Pointer)+4(对齐填充)=16字节

结果究竟是不是这个呢?咱们来验证一下。
首先引入一个pom依赖:性能

`<dependency>
            <groupId>org.openjdk.jol</groupId>
            <artifactId>jol-core</artifactId>
            <version>0.10</version>
        </dependency>`

而后新建一个简单的demo:测试

`package com.zwx.jvm;

import org.openjdk.jol.info.ClassLayout;

public class HeapMemory {
    public static void main(String[] args) {
        Object obj = new Object();
        System.out.println(ClassLayout.parseInstance(obj).toPrintable());
    }
}`

输出结果以下:
在这里插入图片描述
最后的结果是16字节,没有问题,这是由于默认开启了指针压缩,那咱们如今把指针压缩关闭以后再去试试。优化

`-XX:+UseCompressedOops  开启指针压缩
-XX:-UseCompressedOops  关闭指针压缩`

在这里插入图片描述
再次运行,获得以下结果:
在这里插入图片描述
能够看到,这时候已经没有了对齐填充部分了,可是占用大小仍是16位。

下面咱们再来演示一下若是一个对象中带有属性以后的大小。

新建一个类,内部只有一个byte属性:

`package com.zwx.jvm;

public class MyItem {
    byte i = 0;
}`

而后分别在开启指针压缩和关闭指针压缩的场景下分别输出这个类的大小。

`package com.zwx.jvm;

import org.openjdk.jol.info.ClassLayout;

public class HeapMemory {
    public static void main(String[] args) {
        MyItem myItem = new MyItem();
        System.out.println(ClassLayout.parseInstance(myItem).toPrintable());
    }
}`

开启指针压缩,占用16字节:
在这里插入图片描述
关闭指针压缩,占用24字节:
在这里插入图片描述
这个时候就能看出来开启了指针压缩的优点了,若是不断建立大量对象,指针压缩对性能仍是有必定优化的。

对象的访问

建立好一个对象以后,固然须要去访问它,那么当咱们须要访问一个对象的时候,是如何定位到对象的呢?
目前最主流的访问对象方式有两种:句柄访问直接指针访问

  • 句柄访问
    使用句柄访问的话,Java虚拟机会在堆内划分出一块内存来存储句柄池,那么对象当中存储的就是句柄地址,而后句柄池中才会存储对象实例数据和对象类型数据地址。
    在这里插入图片描述
  • 直接指针访问(Hot Spot虚拟机采用的方式)
    直接指针访问的话对象中就会直接存储对象类型数据。
    在这里插入图片描述

句柄访问和直接指针访问对比

上面图形中咱们很容易对比,就是若是使用句柄访问的时候,会多了一次指针定位,可是他也有一个好处就是,假如一个对象被移动(地址改变了),那么只须要改变句柄池的指向就能够了,不须要修改reference对象内的指向,而若是使用直接指针访问,就还须要到局部变量表内修改reference指向。

堆内存

上面咱们提到,在Java对象头当中的Mark Word存储了对象的分代年龄,那么什么是分代年龄呢?

一个对象的分代年龄能够理解为垃圾回收次数,当一个对象通过一次垃圾回收以后还存在,那么分代年龄就会加1,在64位的虚拟机中,分代年龄占了4位,最大值为15。分代年龄默认为0000,随着垃圾回收次数,会逐渐递增。

Java堆内存中按照分代年龄来划分,分为Young区和Old区,对象分配首先会到Young区,达到必定分代年龄(-XX:MaxTenuringThreshold能够设置大小,默认为15)就会进入Old区(注意:若是一个对象太大,那么就会直接进入Old区)。

之因此会这么划分是由于若是整个堆只有一个区的话,那么垃圾回收的时候每次都须要把堆内全部对象都扫描一遍,浪费性能。而其实大部分Java对象的生命周期都是很短的,一旦一个对象回收不少次都回收不掉,能够认为下一次垃圾回收的时候可能也回收不掉,因此Young区和Old区的垃圾回收能够分开进行,只有当Young区在进行垃圾回收以后仍是没有腾出空间,那么再去触发Old区的垃圾回收。
在这里插入图片描述

Young区

如今拆分红了Young区,那咱们看下面一个场景,下面的Young是通过垃圾回收以后的一个概图:
在这里插入图片描述
假如说如今来了一个对象,要占用2个对象的大小,会发现放不下去了,这时候就会触发GC(垃圾回收),可是一旦触发了GC(垃圾回收),对用户线程是有影响的,由于GC过程当中为了确保对象引用不会不断变化,须要中止全部用户线程,Sun把这个事件称之为:Stop the World(STW)。这些在下一篇讲解垃圾回收的时候会详细介绍,这里先不深刻。

因此说通常是越少GC越好,而实际上上图中能够看到至少还能够放入3个对象,只要按照对象都按照顺序放好,那么是能够放得下的,因此这就产生了问题了,明明有空间,可是由于空间不连续,致使对象申请内存失败,致使触发GC了,那么如何解决这种问题呢?

解决的思路就是把Young区的对象按顺序放好,因此就产生了一个方法,把Young区再次划分一下,分为2个区:Eden区Survivor区
在这里插入图片描述
具体操做是:一个对象来了以后,先分配到Eden区,Eden区满了以后,触发GC,通过GC以后,为了防止空间不连续,把幸存下来的对象复制到Survivor区,而后Eden区就能够完整清理掉了,固然这么作是有一个前提的,就是大部分对象都是生命周期极短的,基本一次垃圾回收就能够把Eden区大部分对象回收掉(这个前提是通过测试总结获得的)。

触发GC的时候Survivor区也会一块儿回收,并非说单独只触发Eden区,可是这样问题又来了,Eden区是保证空间基本连续了,可是Survivor区又可能产生空间碎片,致使不连续了,因此就又把Survivor区给一分为二了:
在这里插入图片描述
这个时候工做流程又变成这样了:
首先仍是在Eden区分配空间,Eden区满了以后触发GC,GC以后把幸存对象 复制到S0区(S1区是空的),而后继续在Eden区分配对象,再次触发GC以后若是发现S0区放不下了(产生空间碎片,实际还有空间),那么就把S0区对象复制到S1区,并把幸存对象也复制到S1区,这时候S0区是空的了,并依次反复操做,假如说S0区或者S1区空间对象复制移动了以后仍是放不下,那就说明这时候是真的满了,那就去老年区借点空间过来(这就是担保机制,老年代须要提供这种空间分配担保),假如说老年区空间也不够了,那就会触发Full GC,若是仍是不够,那就会抛出OutOfMemeoyError异常了。

注意:为了确保S0和S1两个区域之间每次复制都能顺利进行,S0和S1两个区的大小必需要保持一致,并且同一时间有一个区域必定是空的。虽说这种作法是会致使了一小部分空间的浪费,可是综合其余性能的提高来讲,是值得的。

Old区

当Young区的对象达到设置的分代年龄以后,对象会进入Old区,Old区满了以后会触发Full GC,若是仍是清理不掉空间,那么就抛出OutOfMemeoyError异常。

名词扫盲

上面提到了不少新的名词,而实际上不少这种名词还有其余叫法,这个仍是以为有必要了解一下。

  • 垃圾回收:简称GC。
  • Minor GC:针对新生代的GC
  • Major GC:针对老年代的GC,通常老年代触发GC的同时也会触发Minor GC,也就等于触发了Full GC。
  • Full GC:新生代+老年代同时发生GC。
  • Young区:新生代
  • Old区:老年代
  • Eden区:暂时没发现有什么中文翻译(伊甸园?)
  • Surcivor区:幸存区
  • S0和S1:也称之为from区和to区,注意from和to两个区是不断互换身份的,且S0和S1必定要相等,而且保证一块区域是空的

一个对象的人生轨迹图

从上面的介绍你们应该有一个大体的印象,一个对象会在Eden区,S0区,S1区,Old区不断流转(固然,一开始就会被回收的短命对象除外),咱们能够获得下面的一个流程图:
在这里插入图片描述

总结

本文主要介绍了一个Java对象在堆内是如何存储的,并结合Java对象的内存布局示范了一个普通对象占用大小问题,而后还分析了堆内的空间划分以及划分缘由,本文中涉及到了GC相关知识均没有深刻讲解,关于GC及GC算法和GC收集器等相关知识将放在下一篇进行详细分析。