JVM规范，垃圾回收

最新推荐文章于 2024-09-08 18:57:40 发布

龙叔的技术笔记

最新推荐文章于 2024-09-08 18:57:40 发布

阅读量203

点赞数

分类专栏： JVM 文章标签： java jvm 面试

本文链接：https://blog.csdn.net/qq_42747210/article/details/114481362

版权

JVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文详细介绍了JVM的重要知识点，包括不同JDK版本下的内存模型变化，如JDK1.6至1.8中永久代到元空间的演变。探讨了对象内存布局，讲解了HotSpot虚拟机的对象头、实例数据和对齐填充。同时，阐述了CMS和G1两种垃圾收集器的工作原理及应用场景。最后，提到了类加载的双亲委派模型，确保了类加载的有序性和一致性。

摘要由CSDN通过智能技术生成

JVM是面试中必问的部分，本文通过思维导图以面向面试的角度整理JVM中不可不知的知识。

在这里插入图片描述
JVM 的全称是「Java Virtual Machine」，也就是我们耳熟能详的 Java 虚拟机。

当然，严格来说JVM也是虚拟机规范，有很多不同的实现，Sun/OracleJDK和OpenJDK中的默认Java虚拟机是HotSpot虚拟机，是目前使用范围最广的Java虚拟机，一般讲到的JVM默认指的就是HotSpot虚拟机。

JVM版本差异

在这里插入图片描述
JDK1.6、JDK1.7、JDK1.8 JVM 内存模型主要有以下差异：
JDK 1.6：有永久代，静态变量存放在永久代上。
JDK 1.7：有永久代，但已经把字符串常量池、静态变量，存放在堆上。逐渐的减少永久代的使用。
JDK 1.8：无永久代，运行时常量池、类常量池，都保存在元数据区，也就是常说的元空间。但字符串常量池仍然存放在堆上。

直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分。

显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括物理内存、SWAP分区或者分页文件）大小以及处理器寻址空间的限制。

元空间从虚拟机 Java 堆中转移到本地内存，默认情况下，元空间的大小仅受本地内存的限制。jdk1.8 以前版本的 class 和 JAR 包数据存储在 PermGen 下面，PermGen 大小是固定的，而且项目之间无法共用，公有的 class，所以比较容易出现 OOM 异常。

升级 JDK 1.8 后，元空间配置参数，-XX:MetaspaceSize=512M XX:MaxMetaspaceSize=1024M。

对象的内存布局

在HotSpot虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。
在这里插入图片描述
HotSpot虚拟机对象的对象头部分包括两类信息。第一类是用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特，官方称它为“Mark Word”。

垃圾回收

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。

Concurrent Mark Sweep收集器运行过程如图：

在这里插入图片描述

Garbage First收集器

G1是一款主要面向服务端应用的垃圾收集器，在多核，大内存机器上使用，是目前垃圾回收器的前沿成果。HotSpot开发团队最初赋予它的期望是（在比较长期的）未来可以替换掉JDK 5中发布的CMS收集器。现在这个期望目标已经实现过半了，JDK 9发布之日，G1宣告取代Parallel Scavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器。

G1收集器运行过程如图：
在这里插入图片描述

双亲委派模型

在这里插入图片描述
加载：“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，在加载阶段，Java虚拟机需要完成以下三件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为堆的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

双亲委派模型：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

在这里插入图片描述
为什么要使用双亲委派模型来组织类加载器之间的关系呢一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的 ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。