【JVM深度解析】JVM中的对象及引用

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 本文通过对象的创建步骤中的检查加载->分配内存->内存空间初始化->设置->对象初始化,对象的内存布局,什么是垃圾的两种算法以及四种引用,讲述JVM中对象及引用。

本文通过对象的创建步骤中的检查加载->分配内存->内存空间初始化->设置->对象初始化,对象的内存布局,什么是垃圾的两种算法以及四种引用,讲述JVM中对象及引用,本篇篇幅较长,适合点赞+收藏。有什么错误希望大家直接指出~

对象的创建

当JVM加载后遇到一条new指令首先检查是否被类加载器加载,如果没有,那必须先执行相应的类加载过程。类加载就是把 class 加载到 JVM 的运行时数据区的过程(类加载后面有专门的专题讲)。

image.gif编辑

一、检查加载

首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用( 符号引用:符号引用以一组符号来描述所引用的目标),并且检查类是否已经被加载。

解析和初始化过。

二、分配内存

接下来虚拟机将为新生对象分配内存。为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。

指针碰撞

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

image.gif编辑

空闲列表

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

image.gif编辑

选择哪种分配方式由 Java 堆是否规整决定,而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。(这部分知识先了解,后续结合垃圾回收器一起去理解)

如果是 Serial、ParNew 等带有压缩的整理的垃圾回收器的话,系统采用的是指针碰撞,既简单又高效。

如果是使用 CMS 这种不带压缩(整理)的垃圾回收器的话,理论上只能采用较复杂的空闲列表。

并发安全

除如何划分可用空间之外,还有另外一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为,即使是仅仅修改一个指针所指向的位置,在并发情况下也并不是线程安全的,可能出现正在给对象 A 分配内存,指针还没来得及修改,对象 B 又同时使用了原来的指针来分配内存的情况。

CAS机制

解决这个问题有两种方案,一种是对分配内存空间的动作进行同步处理——实际上虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性;

分配缓冲

另一种是把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在 Java 堆中预先分配一小块私有内存,也就是本地线程分配缓冲(Thread Local Allocation Buffer,TLAB),JVM 在线程初始化时,同时也会申请一块指定大小的内存,只给当前线程使用,这样每个线程都单独拥有一个 Buffer,如果需要分配内存,就在自己的 Buffer 上分配,这样就不存在竞争的情况,可以大大提升分配效率,当 Buffer 容量不够的时候,再重新从 Eden 区域申请一块继续使用。

TLAB 的目的是在为新对象分配内存空间时,让每个 Java 应用线程能在使用自己专属的分配指针来分配空间,减少同步开销。

TLAB 只是让每个线程有私有的分配指针,但底下存对象的内存空间还是给所有线程访问的,只是其它线程无法在这个区域分配而已。当一个 TLAB 用满(分配指针 top 撞上分配极限 end 了),就新申请一个 TLAB。

参数:

-XX:+UseTLAB:允许在年轻代空间中使用线程本地分配块(TLAB)。默认情况下启用此选项。要禁用 TLAB,请指定-XX:-UseTLAB。(Enables the use of thread-local allocation blocks (TLABs) in the young generation space. This option is enabled by default. To disable the use of TLABs, specify -XX:-UseTLAB.)

三、内存空间初始化

(注意不是构造方法)内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(如 int 值为 0,boolean 值为 false 等等)。这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用,程序能访问到这些字段的数据类型所对应的零值。

四、设置

接下来,虚拟机要对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息(Java classes 在 Java hotspot VM 内部表示为类元数据)、对象的哈希码、对象的 GC 分代年龄等信息。这些信息存放在对象的对象头之中。

五、对象初始化

在上面工作都完成之后,从虚拟机的视角来看,一个新的对象已经产生了,但从 Java 程序的视角来看,对象创建才刚刚开始,所有的字段都还为零值。所以,一般来说,执行 new 指令之后会接着把对象按照程序员的意愿进行初始化(构造方法),这样一个真正可用的对象才算完全产生出来。

对象的内存布局

在 HotSpot 虚拟机中,对象在内存中存储的布局可以分为 3 块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。

image.gif编辑

对象头包括两部分信息,第一部分用于存储对象自身的运行时数据,如哈希码(HashCode)、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。

对象头的另外一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是一个 Java 数组,那么在对象头中还有一块用于记录数组长度的数据。

对齐填充并不是必然存在的,也没有特别的含义,它仅仅起着占位符的作用。由于 HotSpot VM 的自动内存管理系统要求对对象的大小必须是 8 字节的整数倍。当对象其他数据部分没有对齐时,就需要通过对齐填充来补全。

对象的访问定位

建立对象是为了使用对象,我们的 Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象。目前主流的访问方式有使用句柄和直接指针两种。

句柄

如果使用句柄访问的话,那么 Java 堆中将会划分出一块内存来作为句柄池,reference 中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自的具体地址信息。

使用句柄来访问的最大好处就是 reference 中存储的是稳定的句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而 reference 本身不需要修改。

image.gif编辑

直接指针

如果使用直接指针访问, reference 中存储的直接就是对象地址。

这两种对象访问方式各有优势,使用直接指针访问方式的最大好处就是速度更快,它节省了一次指针定位的时间开销,由于对象的访问在 Java 中非常频繁,因此这类开销积少成多后也是一项非常可观的执行成本。

对 Sun HotSpot 而言,它是使用直接指针访问方式进行对象访问的。

image.gif编辑

判断对象存活

在堆里面存放着几乎所有的对象实例,垃圾回收器在进行回收前,要做的事情就是确定这些对象中哪些还是“存活”着,哪些已经“死去”(死去代表着不可能再被任何途径使用得对象了)

什么是垃圾 ?

C 语言申请内存:malloc free ,C++: new delete。 C/C++ 手动回收内存

Java: new。Java 是自动内存回收,编程上简单,系统不容易出错。

手动释放内存,容易出两种类型的问题:

1、忘记回收

2、多次回收

没有任何引用指向的一个对象或者多个对象(循环引用)

引用计数法

在对象中添加一个引用计数器,每当有一个地方引用它,计数器就加 1,当引用失效时,计数器减 1。Python 在用,但主流虚拟机没有使用,因为存在对象相互引用的情况,这个时候需要引入额外的机制来处理,这样做影响效率,

在代码中看到,只保留相互引用的对象还是被回收掉了,说明 JVM 中采用的不是引用计数法。

可达性分析( 面试时重要的知识点,牢记)

来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots 没有任何引用链相连时,则证明此对象是不可用的。

作为 GC Roots 的对象包括下面几种(重点是前面 4 种):

1、虚拟机栈(栈帧中的本地变量表)中引用的对象;各个线程调用方法堆栈中使用到的参数、局部变量、临时变量等。

2、方法区中类静态属性引用的对象;java 类的引用类型静态变量。

3、方法区中常量引用的对象;比如:字符串常量池里的引用。

4、本地方法栈中 JNI(即一般说的 Native 方法)引用的对象。

5、JVM 的内部引用(class 对象、异常对象 NullPointException、OutofMemoryError,系统类加载器)。(非重点)

6、所有被同步锁(synchronized 关键)持有的对象。(非重点)

7、JVM 内部的 JMXBean、JVMTI 中注册的回调、本地代码缓存等(非重点)

8、JVM 实现中的“临时性”对象,跨代引用的对象( 在使用分代模型回收只回收部分代的对象,这个后续会细讲,先大致了解概念)(非重点)

以上的回收都是对象,类的回收条件:

注意 Class  要被回收,条件比较苛刻,必须同时满足以下的条件(仅仅是可以,不代表必然,因为还有一些参数可以进行控制):

1、该类所有的实例都已经被回收,也就是堆中不存在该类的任何实例。

2、加载该类的 ClassLoader 已经被回收。

3、该类对应的 java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。

4、参数控制:-Xnoclassgc:禁用类的垃圾收集(GC) 。这样可以节省一些GC时间, 从而缩短了应用程序运行期间的中断时间。

当您-Xnoclasagc在启动时指定时,应用程序中的类对象在GC期间将保持不变,并且始终被认为是活动的。这可能会导致更多的内存被永久占用,如果不谨慎使用,将抛出内存不足异常。

废弃的常量和静态变量的回收其实就和 Class 回收的条件差不多

Finalize  方法

即使通过可达性分析判断不可达的对象,也不是“非死不可”,它还会处于“缓刑”阶段,真正要宣告一个对象死亡,需要经过两次标记过程,一次是没有找到与 GCRoots 的引用链,它将被第一次标记。随后进行一次筛选(如果对象覆盖了 finalize),我们可以在 finalize 中去拯救。

代码演示:

/**
 * @author macfmc
 * @date 2020/7/31-22:39
 */
public class FinalizeGC {
    public static FinalizeGC instance = null;
    public void isAlive() {
        System.out.println("I am still alive!");
    }
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed");
        FinalizeGC.instance = this;
    }
    public static void main(String[] args) throws Throwable {
        instance = new FinalizeGC();
        //对象进行第1次GC
        instance = null;
        System.gc();
        Thread.sleep(1000);//Finalizer 方法优先级很低,需要等待
        if (instance != null) {
            instance.isAlive();
        } else {
            System.out.println("I am dead! ");
        }
        //对象进行第2次GC
        instance = null;
        System.gc();
        Thread.sleep(1000);
        if (instance != null) {
            instance.isAlive();
        } else {
            System.out.println("I am dead! ");
        }
    }
}

image.gif

运行结果:

finalize method executed
I am still alive!
I am dead!

image.gif

可以看到,对象可以被拯救一次(finalize  执行第一次,但是不会执行第二次)

代码改一下,再来一次。

/**
 * @author macfmc
 * @date 2020/7/31-22:39
 */
public class FinalizeGC {
    public static FinalizeGC instance = null;
    public void isAlive() {
        System.out.println("I am still alive!");
    }
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed");
        FinalizeGC.instance = this;
    }
    public static void main(String[] args) throws Throwable {
        instance = new FinalizeGC();
        //对象进行第1次GC
        instance = null;
        System.gc();
        // Thread.sleep(1000);//Finalizer 方法优先级很低,需要等待
        if (instance != null) 
            instance.isAlive();
        else 
            System.out.println("I am dead! ");
        //对象进行第2次GC
        instance = null;
        System.gc();
        // Thread.sleep(1000);
        if (instance != null) {
            instance.isAlive();
        } else {
            System.out.println("I am dead! ");
        }
    }
}

image.gif

运行结果:

finalize method executed
I am dead! 
I am dead!

image.gif

对象没有被拯救,这个就是 finalize()方法执行缓慢,还没有完成拯救,垃圾回收器就已经回收掉了。

所以建议大家尽量不要使用 finalize, 因为这个方法太不可靠 。 在生产中你很难控制方法的执行或者对象的调用顺序 , 建议大家忘了 finalize  方法 ! 因为在finalize  方法能做的工作,java中有更好的,比如 try-finally或者其他方式可以做得更好

各种引用

强引用

一般的 Object obj = new Object() ,就属于强引用。在任何情况下,只有有强引用关联(与根可达)还在,垃圾回收器就永远不会回收掉被引用的对象。

软引用 SoftReference

一些有用但是并非必需,用软引用关联的对象,系统将要发生内存溢出(OuyOfMemory)之前,这些对象就会被回收(如果这次回收后还是没有足够的空间,才会抛出内存溢出)。参见代码:VM 参数 -Xms10m -Xmx10m -XX:+PrintGC

代码演示:

import java.lang.ref.SoftReference;
import java.util.LinkedList;
import java.util.List;
/**
 * @author macfmc
 * @date 2020/7/31-22:56
 */
public class gcRoot {
    public static void main(String[] args) {
        gcRoot u = new gcRoot(); //new是强引用
        SoftReference<gcRoot> userSoft = new SoftReference<>(u);
        u = null;//干掉强引用,确保这个实例只有userSoft的软引用
        System.out.println(userSoft.get());
        System.gc();//进行- -次GC垃圾回收
        System.out.println("After gc");
        System.out.println(userSoft.get());
        //往堆中填充数据,导致00M
        List<byte[]> list = new LinkedList<>();
        try {
            for (int i = 0; i < 100; ++i) {
                System.out.println("*************" + userSoft.get());
                list.add(new byte[1024 * 1024 * 1]); //1M的对象
            }
        } catch (Throwable e) {
            //抛出了00M异常时打印软引用对象
            System.out.println("Excepti n*************" + userSoft.get());
        }
    }
}

image.gif

运行结果:

main.java.JVM.gcRoot@4554617c
[GC (System.gc())  3341K->856K(125952K), 0.0043645 secs]
[Full GC (System.gc())  856K->662K(125952K), 0.0074266 secs]
After gc
main.java.JVM.gcRoot@4554617c
*************main.java.JVM.gcRoot@4554617c
*************main.java.JVM.gcRoot@4554617c
[GC (Allocation Failure)  33072K->32502K(125952K), 0.0102263 secs]
*************main.java.JVM.gcRoot@4554617c
*************main.java.JVM.gcRoot@4554617c
[GC (Allocation Failure)  64906K->64247K(125952K), 0.0123316 secs]
[Full GC (Ergonomics)  64247K->64149K(194560K), 0.0198417 secs]

image.gif

例如,一个程序用来处理用户提供的图片。如果将所有图片读入内存,这样虽然可以很快的打开图片,但内存空间使用巨大,一些使用较少的图片浪费内存空间,需要手动从内存中移除。如果每次打开图片都从磁盘文件中读取到内存再显示出来,虽然内存占用较少,但一些经常使用的图片每次打开都要访问磁盘,代价巨大。这个时候就可以用软引用构建缓存。

弱引用 WeakReference

一些有用(程度比软引用更低)但是并非必需,用弱引用关联的对象,只能生存到下一次垃圾回收之前,GC 发生时,不管内存够不够,都会被回收。

代码演示:

import java.lang.ref.WeakReference;
/**
 * @author macfmc
 * @date 2020/7/31-22:56
 */
public class gcRoot {
    public static void main(String[] args) {
        gcRoot u = new gcRoot();
        WeakReference<gcRoot> userWeak = new WeakReference<>(u);
        u = null;//干掉强引用,确保这个实例只有userWeak的弱引用
        System.out.println(userWeak.get());
        System.gc();//进行一次GC垃圾回收
        System.out.println("After gc");
        System.out.println(userWeak.get());
    }
}

image.gif

运行结果:

main.java.JVM.gcRoot@4554617c
[GC (System.gc())  3341K->752K(125952K), 0.0014105 secs]
[Full GC (System.gc())  752K->625K(125952K), 0.0103507 secs]
After gc
null

image.gif

注意:软引用 SoftReference 和弱引用 WeakReference,可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候,缓存中的内容是可以被释放的。实际运用(WeakHashMap、ThreadLocal)

虚引用 PhantomReference

幽灵引用,最弱(随时会被回收掉)垃圾回收的时候收到一个通知,就是为了监控垃圾回收器是否正常工作

相关文章
|
1月前
|
存储 算法 Java
散列表的数据结构以及对象在JVM堆中的存储过程
本文介绍了散列表的基本概念及其在JVM中的应用,详细讲解了散列表的结构、对象存储过程、Hashtable的扩容机制及与HashMap的区别。通过实例和图解,帮助读者理解散列表的工作原理和优化策略。
40 1
散列表的数据结构以及对象在JVM堆中的存储过程
|
1月前
|
监控 算法 Java
Java虚拟机(JVM)的垃圾回收机制深度解析####
本文深入探讨了Java虚拟机(JVM)的垃圾回收机制,旨在揭示其背后的工作原理与优化策略。我们将从垃圾回收的基本概念入手,逐步剖析标记-清除、复制算法、标记-整理等主流垃圾回收算法的原理与实现细节。通过对比不同算法的优缺点及适用场景,为开发者提供优化Java应用性能与内存管理的实践指南。 ####
|
12天前
|
存储 Java 开发者
浅析JVM方法解析、创建和链接
上一篇文章《你知道Java类是如何被加载的吗?》分析了HotSpot是如何加载Java类的,本文再来分析下Hotspot又是如何解析、创建和链接类方法的。
|
21天前
|
存储 监控 算法
Java虚拟机(JVM)垃圾回收机制深度解析与优化策略####
本文旨在深入探讨Java虚拟机(JVM)的垃圾回收机制,揭示其工作原理、常见算法及参数调优方法。通过剖析垃圾回收的生命周期、内存区域划分以及GC日志分析,为开发者提供一套实用的JVM垃圾回收优化指南,助力提升Java应用的性能与稳定性。 ####
|
1天前
|
缓存 Java
JVM对象引用
本次课程聚焦JVM对象引用,涵盖强引用、软引用、弱引用和虚引用。强引用是最常见的引用类型,确保对象不会被垃圾回收器回收,适用于需要确保对象存活的场景;软引用在内存不足时会被优先回收,常用于缓存;弱引用的对象随时可能被回收,适合临时对象;虚引用最弱,主要用于接收对象回收通知,进行资源清理。通过合理选择引用类型,可优化内存管理,避免内存泄露。
|
25天前
|
Java 编译器 API
深入解析:JDK与JVM的区别及联系
在Java开发和运行环境中,JDK(Java Development Kit)和JVM(Java Virtual Machine)是两个核心概念,它们在Java程序的开发、编译和运行过程中扮演着不同的角色。本文将深入解析JDK与JVM的区别及其内在联系,为Java开发者提供清晰的技术干货。
24 1
|
2月前
|
缓存 算法 Java
JVM知识体系学习六:JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
这篇文章详细介绍了Java虚拟机(JVM)中的垃圾回收机制,包括垃圾的定义、垃圾回收算法、堆内存的逻辑分区、对象的内存分配和回收过程,以及不同垃圾回收器的工作原理和参数设置。
83 4
JVM知识体系学习六:JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
|
28天前
|
SQL Java 数据库连接
canal-starter 监听解析 storeValue 不一样,同样的sql 一个在mybatis执行 一个在数据库操作,导致解析不出正确对象
canal-starter 监听解析 storeValue 不一样,同样的sql 一个在mybatis执行 一个在数据库操作,导致解析不出正确对象
|
2月前
|
存储 Java
JVM知识体系学习四:排序规范(happens-before原则)、对象创建过程、对象的内存中存储布局、对象的大小、对象头内容、对象如何定位、对象如何分配
这篇文章详细地介绍了Java对象的创建过程、内存布局、对象头的MarkWord、对象的定位方式以及对象的分配策略,并深入探讨了happens-before原则以确保多线程环境下的正确同步。
60 0
JVM知识体系学习四:排序规范(happens-before原则)、对象创建过程、对象的内存中存储布局、对象的大小、对象头内容、对象如何定位、对象如何分配
|
2月前
|
存储 安全 Java
JVM锁的膨胀过程与锁内存变化解析
在Java虚拟机(JVM)中,锁机制是确保多线程环境下数据一致性和线程安全的重要手段。随着线程对共享资源的竞争程度不同,JVM中的锁会经历从低级到高级的膨胀过程,以适应不同的并发场景。本文将深入探讨JVM锁的膨胀过程,以及锁在内存中的变化。
47 1

推荐镜像

更多