【面试题】深入理解Java虚拟机

前言：Java虚拟机面试题推荐配合《深入理解虚拟机第三版》食用效果更佳
主要有三部分：1.Java内存区域，2. 垃圾回收机制，3. 类加载过程

• 📚 博客主页：⭐️这是一只小逸白的博客鸭~⭐️
• 👉 欢迎 关注❤️点赞👍收藏⭐️评论📝
• 😜 小逸白正在备战实习，经常更新面试题和LeetCode题解，欢迎志同道合的朋友互相交流~
• 💙 若有问题请指正，记得关注哦，感谢~

1.1 介绍下 Java 内存区域(运⾏时数据区)

Java 虚拟机在执⾏ Java 程序的过程中会把它管理的内存划分成若⼲个不同的数据区域。JDK. 1.8 和之前的版本略有不同，下⾯会介绍到。
JDK 1.8之前：

JDK 1.8 ：

线程私有的：

• 程序计数器
• 虚拟机栈
• 本地⽅法栈

线程共享的：

• 堆
• ⽅法区
• 直接内存(⾮运⾏时数据区的⼀部分)

程序计数器

程序计数器是⼀块᫾⼩的内存空间，可以看作是当前线程所执⾏的字节码的⾏号指示器。字节码解释器⼯作时通过改变这个计数器的值来选取下⼀条需要执⾏的字节码指令，分⽀、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成。

另外，为了线程切换后能恢复到正确的执⾏位置，每条线程都需要有⼀个独⽴的程序计数器，各线程之间计数器互不影响，独⽴存储，我们称这类内存区域为“线程私有”的内存。

从上⾯的介绍中我们知道程序计数器主要有两个作⽤：

1. 字节码解释器通过改变程序计数器来依次读取指令，从⽽实现代码的流程控制，如：顺序执⾏、
   选择、循环、异常处理。
2. 在多线程的情况下，程序计数器⽤于记录当前线程执⾏的位置，从⽽当线程被切换回来的时候能
   够知道该线程上次运⾏到哪⼉了

注意：程序计数器是唯⼀⼀个不会出现 OutOfMemoryError 的内存区域，它的⽣命周期随着线程的创建⽽创建，随着线程的结束⽽死亡。

Java 虚拟机栈

与程序计数器⼀样，Java虚拟机栈也是线程私有的，它的⽣命周期和线程相同，描述的是 Java ⽅法执⾏的内存模型，每次⽅法调⽤的数据都是通过栈传递的。

Java 内存可以粗糙的区分为堆内存（Heap）和栈内存(Stack),其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。 （实际上，Java虚拟机栈是由⼀个个栈帧组成，⽽每个栈帧中都拥有：局部变量表、操作数栈、动态链接、⽅法出⼝信息。）

局部变量表主要存放了编译器可知的各种数据类型（boolean、byte、char、short、int、float、
long、double）、对象引⽤（reference类型，它不同于对象本身，可能是⼀个指向对象起始地址的引
⽤指针，也可能是指向⼀个代表对象的句柄或其他与此对象相关的位置）。

Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。

• StackOverFlowError： 若Java虚拟机栈的内存⼤⼩不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最⼤深度的时候，就抛出StackOverFlowError异常。
• OutOfMemoryError： 若 Java 虚拟机栈的内存⼤⼩允许动态扩展，且当线程请求栈时内存⽤完了，⽆法再动态扩展了，此时抛出OutOfMemoryError异常。

Java 虚拟机栈也是线程私有的，每个线程都有各⾃的Java虚拟机栈，⽽且随着线程的创建⽽创建，随着线程的死亡⽽死亡。

扩展：那么⽅法/函数如何调⽤？

Java 栈可⽤类⽐数据结构中栈，Java 栈中保存的主要内容是栈帧，每⼀次函数调⽤都会有⼀个对应的栈帧被压⼊Java栈，每⼀个函数调⽤结束后，都会有⼀个栈帧被弹出。

Java⽅法有两种返回⽅式：

1. return 语句。
2. 抛出异常。

不管哪种返回⽅式都会导致栈帧被弹出。

本地⽅法栈

和虚拟机栈所发挥的作⽤⾮常相似，区别是： 虚拟机栈为虚拟机执⾏ Java ⽅法 （也就是字节码）服务，⽽本地⽅法栈则为虚拟机使⽤到的 Native ⽅法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合
⼆为⼀。

本地⽅法被执⾏的时候，在本地⽅法栈也会创建⼀个栈帧，⽤于存放该本地⽅法的局部变量表、操作数栈、动态链接、出⼝信息。

⽅法执⾏完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和OutOfMemoryError 两种异常

堆

Java 虚拟机所管理的内存中最⼤的⼀块，Java 堆是所有线程共享的⼀块内存区域，在虚拟机启动时创建。此内存区域的唯⼀⽬的就是存放对象实例，⼏乎所有的对象实例以及数组都在这⾥分配内存。

Java 堆是垃圾收集器管理的主要区域，因此也被称作GC堆（Garbage Collected Heap）.从垃圾回收的⻆度，由于现在收集器基本都采⽤分代垃圾收集算法，所以Java堆还可以细分为：新⽣代和⽼年代：再细致⼀点有：Eden空间、From Survivor、To Survivor空间等。进⼀步划分的⽬的是更好地回收内存，或者更快地分配内存。

上图所示的 eden区、s0区、s1区都属于新⽣代，tentired 区属于⽼年代。⼤部分情况，对象都会⾸先在 Eden 区域分配，在⼀次新⽣代垃圾回收后，如果对象还存活，则会进⼊ s0 或者 s1，并且对象的年龄还会加 1(Eden区i>Survivor 区后对象的初始年龄变为1)，当它的年龄增加到⼀定程度（默认为15岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

⽅法区

⽅法区与 Java 堆⼀样，是各个线程共享的内存区域，它⽤于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把⽅法区描述为堆的⼀个逻辑部分，但是它却有⼀个别名叫做 Non-Heap（⾮堆），⽬的应该是与 Java 堆区分开来。

⽅法区和永久代的关系

《Java虚拟机规范》只是规定了有⽅法区这么个概念和它的作⽤，并没有规定如何去实现它。那么，在不同的 JVM 上⽅法区的实现肯定是不同的了。 ⽅法区和永久代的关系很像Java中接⼝和类的关系，类实现了接⼝，⽽永久代就是HotSpot虚拟机对虚拟机规范中⽅法区的⼀种实现⽅式。 也就是说，永久代是HotSpot的概念，⽅法区是Java虚拟机规范中的定义，是⼀种规范，⽽永久代是⼀种实现，⼀个是标准⼀个是实现，其他的虚拟机实现并没有永久带这⼀说法。

为什么要将永久代(PermGen)替换为元空间(MetaSpace)呢?

整个永久代有⼀个 JVM 本身设置固定⼤⼩上线，⽆法进⾏调整，⽽元空间使⽤的是直接内存，受本机可⽤内存的限制，并且永远不会得到java.lang.OutOfMemoryError。你可以使⽤ -XX：MaxMetaspaceSize 标志设置最⼤元空间⼤⼩，默认值为 unlimited，这意味着它只受系统内存的限制。 -XX：MetaspaceSize 调整标志定义元空间的初始⼤⼩如果未指定此标志，则 Metaspace 将根据运⾏时的应⽤程序需求动态地重新调整⼤⼩。

运⾏时常量池

运⾏时常量池是⽅法区的⼀部分。Class ⽂件中除了有类的版本、字段、⽅法、接⼝等描述信息外，还有常量池信息（⽤于存放编译期⽣成的各种字⾯量和符号引⽤）

既然运⾏时常量池时⽅法区的⼀部分，⾃然受到⽅法区内存的限制，当常量池⽆法再申请到内存时会抛出 OutOfMemoryError 异常。

JDK1.7及之后版本的 JVM 已经将运⾏时常量池从⽅法区中移了出来，在 Java 堆（Heap）中开辟了⼀块区域存放运⾏时常量池。

直接内存

直接内存并不是虚拟机运⾏时数据区的⼀部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使⽤。⽽且也可能导致 OutOfMemoryError 异常出现。

JDK1.4 中新加⼊的 NIO(New Input/Output) 类，引⼊了⼀种基于通道（Channel） 与缓存区（Buffer） 的 I/O ⽅式，它可以直接使⽤ Native 函数库直接分配堆外内存，然后通过⼀个存储在Java 堆中的 DirectByteBuffer 对象作为这块内存的引⽤进⾏操作。这样就能在⼀些场景中显著提⾼性能，因为避免了在 Java 堆和 Native 堆之间来回复制数据。

本机直接内存的分配不会收到 Java 堆的限制，但是，既然是内存就会受到本机总内存⼤⼩以及处理器寻址空间的限制。

1.2 说⼀下Java对象的创建过程

下图便是 Java 对象的创建过程，我建议最好是能默写出来，并且要掌握每⼀步在做什么。

①类加载检查： 虚拟机遇到⼀条 new 指令时，⾸先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引⽤，并且检查这个符号引⽤代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执⾏相应的类加载过程。

②分配内存： 在类加载检查通过后，接下来虚拟机将为新⽣对象分配内存。对象所需的内存⼤⼩在类加载完成后便可确定，为对象分配空间的任务等同于把⼀块确定⼤⼩的内存从 Java 堆中划分出来。分配⽅式有 “指针碰撞” 和 “空闲列表” 两种，选择那种分配⽅式由 Java 堆是否规整决定，⽽Java堆是否规整⼜由所采⽤的垃圾收集器是否带有压缩整理功能决定。

内存分配的两种⽅式：（补充内容，需要掌握）

选择以上两种⽅式中的哪⼀种，取决于 Java 堆内存是否规整。⽽ Java 堆内存是否规整，取决于 GC收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的

内存分配并发问题（补充内容，需要掌握）

在创建对象的时候有⼀个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采⽤两种⽅式来保证线程安全：

• CAS+失败重试： CAS 是乐观锁的⼀种实现⽅式。所谓乐观锁就是，每次不加锁⽽是假设没有冲突⽽去完成某项操作，如果因为冲突失败就重试，直到成功为⽌。虚拟机采⽤ CAS 配上失败重试的⽅式保证更新操作的原⼦性。
• TLAB： 为每⼀个线程预先在Eden区分配⼀块⼉内存，JVM在给线程中的对象分配内存时，⾸先在TLAB分配，当对象⼤于TLAB中的剩余内存或TLAB的内存已⽤尽时，再采⽤上述的CAS进⾏内存分配

③初始化零值： 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象
头），这⼀步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使⽤，程序能访问到这些字段的数据类型所对应的零值。

④设置对象头： 初始化零值完成之后，虚拟机要对对象进⾏必要的设置，例如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运⾏状态的不同，如是否启⽤偏向锁等，对象头会有不同的设置⽅式。

⑤执⾏ init ⽅法： 在上⾯⼯作都完成之后，从虚拟机的视⻆来看，⼀个新的对象已经产⽣了，但从Java 程序的视⻆来看，对象创建才刚开始， <init> ⽅法还没有执⾏，所有的字段都还为零。所以⼀般来说，执⾏ new 指令之后会接着执⾏ <init> ⽅法，把对象按照程序员的意愿进⾏初始化，这样⼀个真正可⽤的对象才算完全产⽣出来。

1.3 对象的访问定位有哪两种⽅式?

建⽴对象就是为了使⽤对象，我们的Java程序通过栈上的 reference 数据来操作堆上的具体对象。对象的访问⽅式有虚拟机实现⽽定，⽬前主流的访问⽅式有①使⽤句柄和②直接指针两种：

1. 句柄： 如果使⽤句柄的话，那么Java堆中将会划分出⼀块内存来作为句柄池，reference 中存储的就是对象的句柄地址，⽽句柄中包含了对象实例数据与类型数据各⾃的具体地址信息；
   

2. 直接指针： 如果使⽤直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，⽽reference 中存储的直接就是对象的地址。
   
   这两种对象访问⽅式各有优势。使⽤句柄来访问的最⼤好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，⽽ reference 本身不需要修改。使⽤直接指针访问⽅式最⼤的好处就是速度快，它节省了⼀次指针定位的时间开销。

1.4 说⼀下堆内存中对象的分配的基本策略

堆空间的基本结构：

上图所示的 eden区、s0区、s1区都属于新⽣代，tentired 区属于⽼年代。⼤部分情况，对象都会⾸先在 Eden 区域分配，在⼀次新⽣代垃圾回收后，如果对象还存活，则会进⼊ s0 或者 s1，并且对象的年龄还会加 1(Eden区i>Survivor 区后对象的初始年龄变为1)，当它的年龄增加到⼀定程度（默认为15岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

另外，⼤对象和⻓期存活的对象会直接进⼊⽼年代。

1.5 Minor Gc和Full GC 有什么不同呢？

⼤多数情况下，对象在新⽣代中 eden 区分配。当 eden 区没有⾜够空间进⾏分配时，虚拟机将发起⼀次Minor GC。

• 新⽣代GC（Minor GC）:指发⽣新⽣代的的垃圾收集动作，Minor GC⾮常频繁，回收速度⼀般也比较快。
• ⽼年代GC（Major GC/Full GC）:指发⽣在⽼年代的GC，出现了Major GC经常会伴随⾄少⼀次的Minor GC（并⾮绝对），Major GC的速度⼀般会⽐Minor GC的慢10倍以上。

2.1 如何判断对象是否死亡?(两种⽅法)

堆中⼏乎放着所有的对象实例，对堆垃圾回收前的第⼀步就是要判断哪些对象已经死亡（即不能再被任何途径使⽤的对象）。

引⽤计数法

给对象中添加⼀个引⽤计数器，每当有⼀个地⽅引⽤它，计数器就加1；当引⽤失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使⽤的。

可达性分析算法

这个算法的基本思想就是通过⼀系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所⾛过的路径称为引⽤链，当⼀个对象到 GC Roots 没有任何引⽤链相连的话，则证明此对象是不可⽤的。

2.2 简单的介绍⼀下强引用,软引用,弱引用,虚引用

⽆论是通过引⽤计数法判断对象引⽤数量，还是通过可达性分析法判断对象的引⽤链是否可达，判定对象的存活都与“引⽤”有关。

JDK1.2之前，Java中引⽤的定义很传统：如果reference类型的数据存储的数值代表的是另⼀块内存的起始地址，就称这块内存代表⼀个引⽤。

JDK1.2以后，Java对引⽤的概念进⾏了扩充，将引⽤分为强引⽤、软引⽤、弱引⽤、虚引⽤四种（引⽤强度逐渐减弱）

强引⽤(StrongReference)

以前我们使⽤的⼤部分引⽤实际上都是强引⽤，这是使⽤最普遍的引⽤。如果⼀个对象具有强引⽤，那就类似于必不可少的⽣活⽤品，垃圾回收器绝不会回收它。当内存空 间不⾜，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终⽌，也不会靠随意回收具有强引⽤的对象来解决内存不⾜问题。

软引用(SoftReference)

如果⼀个对象只具有软引⽤，那就类似于可有可⽆的⽣活⽤品。如果内存空间⾜够，垃圾回收器就不会回收它，如果内存空间不⾜了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使⽤。软引⽤可⽤来实现内存敏感的⾼速缓存。

软引⽤可以和⼀个引⽤队列（ReferenceQueue）联合使⽤，如果软引⽤所引⽤的对象被垃圾回收，JAVA虚拟机就会把这个软引⽤加⼊到与之关联的引⽤队列中。

弱引⽤(WeakReference)

如果⼀个对象只具有弱引⽤，那就类似于可有可⽆的⽣活⽤品。弱引⽤与软引⽤的区别在于：只具有弱引⽤的对象拥有更短暂的⽣命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，⼀旦发现了只具有弱引⽤的对象，不管当前内存空间⾜够与否，都会回收它的内存。不过，由于垃圾回收器是⼀个优先级很低的线程， 因此不⼀定会很快发现那些只具有弱引⽤的对象。

弱引⽤可以和⼀个引⽤队列（ReferenceQueue）联合使⽤，如果弱引⽤所引⽤的对象被垃圾回收，Java虚拟机就会把这个弱引⽤加⼊到与之关联的引⽤队列中。

虚引⽤（PhantomReference）

"虚引⽤"顾名思义，就是形同虚设，与其他⼏种引⽤都不同，虚引⽤并不会决定对象的⽣命周期。如果⼀个对象仅持有虚引⽤，那么它就和没有任何引⽤⼀样，在任何时候都可能被垃圾回收。

虚引⽤主要⽤来跟踪对象被垃圾回收的活动。

虚引⽤与软引⽤和弱引⽤的⼀个区别在于： 虚引⽤必须和引⽤队列（ReferenceQueue）联合使⽤。当垃 圾回收器准备回收⼀个对象时，如果发现它还有虚引⽤，就会在回收对象的内存之前，把这个虚引⽤加⼊到与之关联的引⽤队列中。程序可以通过判断引⽤队列中是 否已经加⼊了虚引⽤，来了解被引⽤的对象是否将要被垃圾回收。程序如果发现某个虚引⽤已经被加⼊到引⽤队列，那么就可以在所引⽤的对象的内存被回收之前采取必要的⾏动。

特别注意，在程序设计中⼀般很少使⽤弱引⽤与虚引⽤，使⽤软引⽤的情况᫾多，这是因为软引⽤可以加速JVM对垃圾内存的回收速度，可以维护系统的运⾏安全，防⽌内存溢出（OutOfMemory）等问题的产⽣。

2.3 如何判断⼀个常量是废弃常量?

运⾏时常量池主要回收的是废弃的常量。那么，我们如何判断⼀个常量是废弃常量呢？

假如在常量池中存在字符串 “abc”，如果当前没有任何String对象引⽤该字符串常量的话，就说明常量"abc" 就是废弃常量，如果这时发⽣内存回收的话⽽且有必要的话，“abc” 就会被系统清理出常量池。

2.4 如何判断⼀个类是⽆⽤的类?

⽅法区主要回收的是⽆⽤的类，那么如何判断⼀个类是⽆⽤的类的呢？

判定⼀个常量是否是“废弃常量”比较简单，⽽要判定⼀个类是否是“⽆⽤的类”的条件则相对苛刻许多。类需要同时满⾜下⾯3个条件才能算是 “⽆⽤的类” ：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地⽅被引⽤，⽆法在任何地⽅通过反射访问该类的⽅法。

虚拟机可以对满⾜上述3个条件的⽆⽤类进⾏回收，这⾥说的仅仅是“可以”，⽽并不是和对象⼀样不使
⽤了就会必然被回收。

2.5 垃圾收集有哪些算法，各⾃的特点？

标记-清除算法

算法分为“标记”和“清除”阶段：⾸先标记出所有需要回收的对象，在标记完成后统⼀回收所有被标记的对象。它是最基础的收集算法，后续的算法都是对其不⾜进⾏改进得到。这种垃圾收集算法会带来两个明显的问题：

1. 效率问题
2. 空间问题（标记清除后会产⽣⼤量不连续的碎⽚）

标记-复制算法

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为⼤⼩相同的两块，每次使⽤其中的⼀块。当这⼀块的内存使⽤完后，就将还存活的对象复制到另⼀块去，然后再把使⽤的空间⼀次清理掉。这样就使每次的内存回收都是对内存区间的⼀半进⾏回收。

标记-整理算法

根据⽼年代的特点特出的⼀种标记算法，标记过程仍然与“标记-清除”算法⼀样，但后续步骤不是直接对可回收对象回收，⽽是让所有存活的对象向⼀端移动，然后直接清理掉端边界以外的内存。

分代收集算法

当前虚拟机的垃圾收集都采⽤分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为⼏块。⼀般将java堆分为新⽣代和⽼年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
⽐如在新⽣代中，每次收集都会有⼤量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。⽽⽼年代的对象存活⼏率是⽐较⾼的，⽽且没有额外的空间对它进⾏分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进⾏垃圾收集。

2.6 HotSpot为什么要分为新⽣代和⽼年代？

主要是为了提升GC效率。上⾯提到的分代收集算法已经很好的解释了这个问题。

2.7 常⻅的垃圾回收器有那些?

如果说收集算法是内存回收的⽅法论，那么垃圾收集器就是内存回收的具体实现。

虽然我们对各个收集器进⾏⽐᫾，但并⾮要挑选出⼀个最好的收集器。因为知道现在为⽌还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应⽤场景选择适合⾃⼰的垃圾收集器。试想⼀下：如果有⼀种四海之内、任何场景下都适⽤的完美收集器存在，那么我们的HotSpot虚拟机就不会实现那么多不同的垃圾收集器了。

2.7.1 Serial收集器

Serial（串⾏）收集器收集器是最基本、历史最悠久的垃圾收集器了。⼤家看名字就知道这个收集器是⼀个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使⽤⼀条垃圾收集线程去完成垃圾收集⼯作，更重要的是它在进⾏垃圾收集⼯作的时候必须暂停其他所有的⼯作线程（ “Stop The World”），直到它收集结束。

新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。

虚拟机的设计者们当然知道Stop The World带来的不良⽤户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。

但是Serial收集器有没有优于其他垃圾收集器的地⽅呢？当然有，它简单⽽⾼效（与其他收集器的单线程相⽐）。Serial收集器由于没有线程交互的开销，⾃然可以获得很⾼的单线程收集效率。Serial收集器对于运⾏在Client模式下的虚拟机来说是个不错的选择。

2.7.2 ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使⽤多线程进⾏垃圾收集外，其余⾏为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全⼀样。

新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。

它是许多运⾏在 Server 模式下的虚拟机的⾸要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后⾯会介绍到）配合⼯作。

并⾏和并发概念补充：

• 并⾏（Parallel） ：指多条垃圾收集线程并⾏⼯作，但此时⽤户线程仍然处于等待状态。
• 并发（Concurrent）：指⽤户线程与垃圾收集线程同时执⾏（但不⼀定是并⾏，可能会交替执⾏），⽤户程序在继续运⾏，⽽垃圾收集器运⾏在另⼀个 CPU 上。

2.7.3 Parallel Scavenge 收集器

Parallel Scavenge 收集器也是使⽤复制算法的多线程收集器，它看上去⼏乎和 ParNew 都⼀样。 那么它有什么特别之处呢？

Parallel Scavenge 收集器关注点是吞吐量（⾼效率的利⽤ CPU）。CMS 等垃圾收集器的关注点更多的是⽤户线程的停顿时间（提⾼⽤户体验）。所谓吞吐量就是 CPU 中⽤于运⾏⽤户代码的时间与 CPU 总消耗时间的⽐值。 Parallel Scavenge 收集器提供了很多参数供⽤户找到最合适的停顿时间或最⼤吞吐量，如果对于收集器运作不太了解，⼿⼯优化存在困难的时候，使⽤Parallel Scavenge 收集器配合⾃适应调节策略，把内存管理优化交给虚拟机去完成也是⼀个不错的选择。

新⽣代采⽤复制算法，⽼年代采⽤标记-整理算法。

这是 JDK1.8 默认收集器

使⽤ java -XX:+PrintCommandLineFlags -version 命令查看

-XX:InitialHeapSize=262921408 -XX:MaxHeapSize=4206742528 -
XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -
XX:+UseCompressedOops -XX:+UseParallelGC
java version “1.8.0_211”
Java™ SE Runtime Environment (build 1.8.0_211-b12)
Java HotSpot™ 64-Bit Server VM (build 25.211-b12, mixed mode)

JDK1.8 默认使⽤的是 Parallel Scavenge + Parallel Old，如果指定了-XX:+UseParallelGC 参数，则默认指定了-XX:+UseParallelOldGC，可以使⽤-XX:-UseParallelOldGC 来禁⽤该功能

2.7.4 Serial Old 收集器

Serial 收集器的⽼年代版本，它同样是⼀个单线程收集器。它主要有两⼤⽤途：⼀种⽤途是在JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使⽤，另⼀种⽤途是作为 CMS 收集器的后备⽅案。

2.7.5 Parallel Old 收集器

Parallel Scavenge 收集器的⽼年代版本。使⽤多线程和“标记-整理”算法。在注重吞吐量以及CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

2.7.6 CMS 收集器

CMS（Concurrent Mark Sweep）收集器是⼀种以获取最短回收停顿时间为⽬标的收集器。它⾮常符合在注重⽤户体验的应⽤上使⽤。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第⼀款真正意义上的并发收集器，它第⼀次实现了让垃圾收集线程与⽤户线程（基本上）同时⼯作。

从名字中的Mark Sweep这两个词可以看出，CMS 收集器是⼀种 “标记-清除”算法实现的，它的运作过程相⽐于前⾯⼏种垃圾收集器来说更加复杂⼀些。整个过程分为四个步骤：

• 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
• 并发标记： 同时开启 GC 和⽤户线程，⽤⼀个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为⽤户线程可能会不断的更新引⽤域，所以 GC 线程⽆法保证可达性分析的实时性。所以这个算法⾥会跟踪记录这些发⽣引⽤更新的地⽅。
• 重新标记： 重新标记阶段就是为了修正并发标记期间因为⽤户程序继续运⾏⽽导致标记产⽣变动的那⼀部分对象的标记记录，这个阶段的停顿时间⼀般会⽐初始标记阶段的时间稍⻓，远远⽐并发标记阶段时间短
• 并发清除： 开启⽤户线程，同时 GC 线程开始对未标记的区域做清扫。

从它的名字就可以看出它是⼀款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下⾯三个明显的缺点：

• 对 CPU 资源敏感；
• ⽆法处理浮动垃圾；
• 它使⽤的回收算法-“标记-清除”算法会导致收集结束时会有⼤量空间碎⽚产⽣。

2.7.7 G1 收集器

G1 (Garbage-First) 是⼀款⾯向服务器的垃圾收集器,主要针对配备多颗处理器及⼤容量内存的机器. 以极⾼概率满⾜ GC 停顿时间要求的同时,还具备⾼吞吐量性能特征.

被视为 JDK1.7 中 HotSpot 虚拟机的⼀个重要进化特征。它具备⼀下特点：

• 并⾏与并发：G1 能充分利⽤ CPU、多核环境下的硬件优势，使⽤多个 CPU（CPU 或者CPU 核⼼）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执⾏的 GC 动作，G1 收集器仍然可以通过并发的⽅式让 java 程序继续执⾏。
• 分代收集：虽然 G1 可以不需要其他收集器配合就能独⽴管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合：与 CMS 的“标记–清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
• 可预测的停顿：这是 G1 相对于 CMS 的另⼀个⼤优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建⽴可预测的停顿时间模型，能让使⽤者明确指定在⼀个⻓度为 M 毫秒的时间⽚段内。

G1 收集器的运作⼤致分为以下⼏个步骤：

• 初始标记
• 并发标记
• 最终标记 （前三步都与CMS收集器相同）
• 筛选回收：负责更新的Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来指定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧的Region的全部空间。这里面的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并发完成的。

G1 收集器在后台维护了⼀个优先列表，每次根据允许的收集时间，优先选择回收价值最⼤的Region(这也就是它的名字 Garbage-First 的由来)。这种使⽤ Region 划分内存空间以及有优先级的区域回收⽅式，保证了 G1 收集器在有限时间内可以尽可能⾼的收集效率（把内存化整为零）。

3.1 类加载过程

知道类加载的过程吗？
类加载过程：加载y>连接y>初始化。连接过程⼜可分为三步:验证y>准备y>解析。

那加载这⼀步做了什么?

类加载过程的第⼀步，主要完成下⾯3件事情：

1. 通过全类名获取定义此类的⼆进制字节流
2. 将字节流所代表的静态存储结构转换为⽅法区的运⾏时数据结构
3. 在内存中⽣成⼀个代表该类的 Class 对象,作为⽅法区这些数据的访问⼊⼝

虚拟机规范多上⾯这3点并不具体，因此是⾮常灵活的。⽐如：“通过全类名获取定义此类的⼆进制字节流” 并没有指明具体从哪⾥获取、怎样获取。⽐如：⽐᫾常⻅的就是从 ZIP 包中读取（⽇后出现的JAR、EAR、WAR格式的基础）、其他⽂件⽣成（典型应⽤就是JSP）等等。

⼀个⾮数组类的加载阶段（加载阶段获取类的⼆进制字节流的动作）是可控性最强的阶段，这⼀步我们可以去完成还可以⾃定义类加载器去控制字节流的获取⽅式（重写⼀个类加载器的 loadClass() ⽅法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

类加载器、双亲委派模型也是⾮常重要的知识点，这部分内容会在后⾯的问题中单独介绍到。

加载阶段和连接阶段的部分内容是交叉进⾏的，加载阶段尚未结束，连接阶段可能就已经开始了。

知道哪些类加载器?

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且
全部继承⾃ java.lang.ClassLoader ：

1. BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由C++实现，负责加载%JAVA_HOME%/lib ⽬录下的jar包和类或者或被 -Xbootclasspath 参数指定的路径中的所有类。
2. ExtensionClassLoader(扩展类加载器) ：主要负责加载⽬录 %JRE_HOME%/lib/ext ⽬录下的jar包和类，或被 java.ext.dirs 系统变量所指定的路径下的jar包。
3. AppClassLoader(应⽤程序类加载器) :⾯向我们⽤户的加载器，负责加载当前应⽤classpath下
   的所有jar包和类。

3.2 双亲委派模型介绍

每⼀个类都有⼀个对应它的类加载器。系统中的 ClassLoder 在协同⼯作的时候会默认使⽤ 双亲委派模型 。即在类加载的时候，系统会⾸先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，⾸先会把该请求委派该⽗类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当⽗类加载器⽆法处理时，才由⾃⼰来处理。当⽗类加载器为null时，会使⽤启动类加载器 BootstrapClassLoader 作为⽗类加载器。

每个类加载都有⼀个⽗类加载器，我们通过下⾯的程序来验证。

public class ClassLoaderDemo {
	 public static void main(String[] args) {
		 System.out.println("ClassLodarDemo's ClassLoader is " +
		ClassLoaderDemo.class.getClassLoader());
		 System.out.println("The Parent of ClassLodarDemo's ClassLoader
		is " + ClassLoaderDemo.class.getClassLoader().getParent());
		 System.out.println("The GrandParent of ClassLodarDemo's
		ClassLoader is " +
		ClassLoaderDemo.class.getClassLoader().getParent().getParent());
	 }
}

Output

ClassLodarDemo's ClassLoader is
sun.misc.Launcher$AppClassLoader@18b4aac2
The Parent of ClassLodarDemo's ClassLoader is
sun.misc.Launcher$ExtClassLoader@1b6d3586
The GrandParent of ClassLodarDemo's ClassLoader is null

AppClassLoader 的⽗类加载器为 ExtClassLoader ExtClassLoader 的⽗类加载器为null，null并不代表 ExtClassLoader 没有⽗类加载器，⽽是 Bootstrap ClassLoader 。

其实这个双亲翻译的容易让别⼈误解，我们⼀般理解的双亲都是⽗⺟，这⾥的双亲更多地表达的是“⽗⺟这⼀辈”的⼈⽽已，并不是说真的有⼀个 Mather ClassLoader 和⼀个 Father ClassLoader 。另外，类加载器之间的“⽗⼦”关系也不是通过继承来体现的，是由“优先级”来决定。

双亲委派模型实现源码分析

双亲委派模型的实现代码⾮常简单，逻辑⾮常清晰，都集中在 java.lang.ClassLoader 的loadClass() 中，相关代码如下所示。

private final ClassLoader parent;
protected Class<?> loadClass(String name, boolean resolve)
	 throws ClassNotFoundException
	 {
		 synchronized (getClassLoadingLock(name)) {
		 // ⾸先，检查请求的类是否已经被加载过
		 Class<?> c = findLoadedClass(name);
		 if (c WX null) {
			long t0 = System.nanoTime();
		 try {
		 if (parent êX null) {//⽗加载器不为空，调⽤⽗加载器
			loadClass()⽅法处理
		 	c = parent.loadClass(name, false);
		 } else {//⽗加载器为空，使⽤启动类加载器
			BootstrapClassLoader 加载
			 c = findBootstrapClassOrNull(name);
		 }
		 } catch (ClassNotFoundException e) {
		 	//抛出异常说明⽗类加载器⽆法完成加载请求
		 }
		 
		 if (c WX null) {
		 	long t1 = System.nanoTime();
		 	//⾃⼰尝试加载
		 	c = findClass(name);
		 // this is the defining class loader; record the
			stats
			 
			sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
			 
			sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
			 sun.misc.PerfCounter.getFindClasses().increment();
			 }
		 }
		 if (resolve) {
		 resolveClass(c);
		 }
		 return c;
	 }
 }

双亲委派模型带来了什么好处呢？

双亲委派模型保证了Java程序的稳定运⾏，可以避免类的重复加载（JVM 区分不同类的⽅式不仅仅根据类名，相同的类⽂件被不同的类加载器加载产⽣的是两个不同的类），也保证了 Java 的核⼼ API 不被篡改。如果不⽤没有使⽤双亲委派模型，⽽是每个类加载器加载⾃⼰的话就会出现⼀些问题，⽐如我们编写⼀个称为 java.lang.Object 类的话，那么程序运⾏的时候，系统就会出现多个不同的Object 类。

如果我们不想⽤双亲委派模型怎么办？

为了避免双亲委托机制，我们可以⾃⼰定义⼀个类加载器，然后重载 loadClass() 即可。

如何⾃定义类加载器?

除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承⾃java.lang.ClassLoader 。如果我们要⾃定义⾃⼰的类加载器，很明显需要继承 ClassLoader 。

参考资料：JavaGuide，只为方便自己复习，如有不妥望私聊删除