【JVM系列4】new Object()到底占用几个字节,看完这篇就彻底明白了
package com.zwx.jvm;
public class HeapMemory {
private Object obj1 = new Object();
public static void main(String[] args) {
Object obj2 = new Object();
}
}
上面的代码中,obj1 和obj2在内存中有什么区别?
答: 这个obj1是存在方法区的,而new会创建一个对象实例,对象实例是存储在堆内的,于是就有了下面这幅图(方法区指向堆):
而obj2 是属于方法内的局部变量,存储在Java虚拟机栈内的栈帧中的局部变量表内,这就是经典的栈指向堆:
疑问: 堆内的示例对象是如何知道自己属于哪个Class,也就是说这个实例是如何知道自己所对应的类元信息的呢?
Java内存模型
对象内存中可以分为三块区域:对象头(Header),实例数据(Instance Data)和对齐填充(Padding),以64位操作系统为例(未开启指针压缩的情况) Java对象布局如下图所示:
上图中的对齐填充不是一定有的,如果对象头和实例数据加起来刚好是8字节的倍数,那么就不需要对齐填充。
一个面试问题
Object obj=new Object()占用多少字节?
以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;
}
开启指针压缩,占用16字节:
关闭指针压缩,占用24字节:
这个时候就能看出来开启了指针压缩的优势了,如果不断创建大量对象,指针压缩对性能还是有一定优化的。
对象的访问
目前最主流的访问对象方式有两种:句柄访问和直接指针访问。
句柄访问
使用句柄访问的话,Java虚拟机会在堆内划分出一块内存来存储句柄池,那么对象当中存储的就是句柄地址,然后句柄池中才会存储对象实例数据和对象类型数据地址。
直接指针访问(Hot Spot虚拟机采用的方式)
直接指针访问的话对象中就会直接存储对象类型数据。
句柄访问和直接指针访问对比
使用句柄访问的时候,会多了一次指针定位,但是他也有一个好处就是,假如一个对象被移动(地址改变了),那么只需要改变句柄池的指向就可以了,不需要修改reference对象内的指向,而如果使用直接指针访问,就还需要到局部变量表内修改reference指向。
堆内存
Java堆内存中按照分代年龄来划分,分为Young区和Old区,对象分配首先会到Young区,达到一定分代年龄(-XX:MaxTenuringThreshold可以设置大小,默认为15)就会进入Old区(注意:如果一个对象太大,那么就会直接进入Old区)。
之所以会这么划分是因为如果整个堆只有一个区的话,那么垃圾回收的时候每次都需要把堆内所有对象都扫描一遍,浪费性能。而其实大部分Java对象的生命周期都是很短的,一旦一个对象回收很多次都回收不掉,可以认为下一次垃圾回收的时候可能也回收不掉,所以Young区和Old区的垃圾回收可以分开进行,只有当Young区在进行垃圾回收之后还是没有腾出空间,那么再去触发Old区的垃圾回收。
触发了GC(垃圾回收),对用户线程是有影响的,因为GC过程中为了确保对象引用不会不断变化,需要停止所有用户线程,Sun把这个事件称之为:Stop the World(STW)。
明明有空间,但是因为空间不连续,导致对象申请内存失败,导致触发GC了,那么如何解决这种问题呢?
解决的思路就是把Young区的对象按顺序放好,所以就产生了一个方法,把Young区再次划分一下,分为2个区:Eden区和Survivor区。
大部分对象都是生命周期极短的,基本一次垃圾回收就可以把Eden区大部分对象回收掉(这个前提是经过测试总结得到的)。
触发GC的时候Survivor区也会一起回收,并不是说单独只触发Eden区,但是这样问题又来了,Eden区是保证空间基本连续了,但是Survivor区又可能产生空间碎片,导致不连续了,所以就又把Survivor区给一分为二了:
名词扫盲
- 垃圾回收:简称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一定要相等,并且保证一块区域是空的