从一个Java对象看JVM内存模型及对象生命周期-白红宇

从一个Java对象看JVM内存模型及对象生命周期

阅读量：4296 次

发布时间：2019-05-27

本文共 2759 字，大约阅读时间需要 9 分钟。

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依赖：


               
    
     org.openjdk.jol
                
    
     jol-core
                
    
     0.10

新建一个简单的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区给一分为二了：