Java 大厂八股文面试专题-设计模式 工厂方法模式、策略模式、责任链模式-CSDN博客

JVM相关面试题

1 JVM组成

1.1 JVM由那些部分组成，运行流程是什么？

难易程度：☆☆☆
出现频率：☆☆☆☆

JVM是什么

Java Virtual Machine Java程序的运行环境（java二进制字节码的运行环境）

好处：

• 一次编写，到处运行
• 自动内存管理，垃圾回收机制

JVM由哪些部分组成，运行流程是什么？

从图中可以看出 JVM 的主要组成部分

• ClassLoader（类加载器）
• Runtime Data Area（运行时数据区，内存分区）
• Execution Engine（执行引擎）
• Native Method Library（本地库接口）

运行流程：

（1）类加载器（ClassLoader）把Java代码转换为字节码

（2）运行时数据区（Runtime Data Area）把字节码加载到内存中，而字节码文件只是JVM的一套指令集规范，并不能直接交给底层系统去执行，而是有执行引擎运行

（3）执行引擎（Execution Engine）将字节码翻译为底层系统指令，再交由CPU执行去执行，此时需要调用其他语言的本地库接口（Native Method Library）来实现整个程序的功能。

1.2 什么是程序计数器？

难易程度：☆☆☆
出现频率：☆☆☆☆

程序计数器：

线程私有的，内部保存的字节码的行号。用于记录正在执行的字节码指令的地址。

javap -verbose xx.class 打印堆栈大小，局部变量的数量和方法的参数。

java虚拟机对于多线程是通过线程轮流切换并且分配线程执行时间。在任何的一个时间点上，一个处理器只会处理执行一个线程，如果当前被执行的这个线程它所分配的执行时间用完了【挂起】。处理器会切换到另外的一个线程上来进行执行。并且这个线程的执行时间用完了，接着处理器就会又来执行被挂起的这个线程。

那么现在有一个问题就是，当前处理器如何能够知道，对于这个被挂起的线程，它上一次执行到了哪里？那么这时就需要从程序计数器中来回去到当前的这个线程他上一次执行的行号，然后接着继续向下执行。

程序计数器是JVM规范中唯一一个没有规定出现OOM的区域，所以这个空间也不会进行GC。

1.3 你能给我详细的介绍Java堆吗?

难易程度：☆☆☆
出现频率：☆☆☆☆

线程共享的区域：主要用来保存对象实例，数组等，当堆中没有内存空间可分配给实例，也无法再扩展时，则抛出OutOfMemoryError异常。

• 年轻代被划分为三部分，
  • Eden区和两个大小严格相同的Survivor(幸存者)区，根据JVM的策略，在经过几次垃圾收集后，任然存活于Survivor的对象将被移动到老年代区间。
• 老年代主要保存生命周期长的对象，一般是一些老的对象
• 元空间保存的类信息、静态变量、常量、编译后的代码

1.7和1.8 堆的区别

为了避免方法区出现OOM，所以在java8中将堆上的方法区【永久代】给移动到了本地内存上，重新开辟了一块空间，叫做元空间。那么现在就可以避免掉OOM的出现了。

元空间(MetaSpace)介绍

在 HotSpot JVM 中，永久代（ ≈ 方法区）中用于存放类和方法的元数据以及常量池，比如Class 和 Method。每当一个类初次被加载时 它的元数据都会放到永久代。

永久代是有大小限制的，因此如果加载的类太多，很有可能导致永久代内存溢出，即OutOfMemoryError，为此不得不对虚拟机做调优。

那么，Java 8 中 PermGen 为什么被移出 HotSpot JVM 了？

官网给出了解释：JEP 122: Remove the Permanent Generation

This is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation.移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代。

1）由于 PermGen 内存经常会溢出，引发OutOfMemoryError，因此 JVM 的开发者希望这一块内存可以更灵活地被管理，不要再经常出现这样的 OOM。

2）移除 PermGen 可以促进 HotSpot JVM 与 JRockit VM 的融合，因为 JRockit 没有永久代。

准确来说，Perm 区中的字符串常量池被移到了堆内存中是在 Java7 之后，Java 8 时，PermGen 被元空间代替，其他内容比如类元信息、字段、静态属性、方法、常量等都移动到元空间区。比如 java/lang/Object 类元信息、静态属性 System.out、整型常量等。

元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现。

不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

1.4 什么是虚拟机栈

难易程度：☆☆☆
出现频率：☆☆☆☆

Java Virtual machine Stacks (java 虚拟机栈)

• 每个线程运行时所需要的内存，称为虚拟机栈，先进后出
• 每个栈由多个栈帧（frame）组成，对应着每次方法调用时所占用的内存
• 每个线程只能有一个活动栈帧，对应着当前正在执行的那个方法

1. 垃圾回收是否涉及栈内存？

垃圾回收主要指就是堆内存，当栈帧弹栈以后，内存就会释放

1. 栈内存分配越大越好吗？

未必，默认的栈内存通常为1024k

栈帧过大会导致线程数变少，例如，机器总内存为512m，目前能活动的线程数则为512个，如果把栈内存改为2048k，那么能活动的栈帧就会减半

1. 方法内的局部变量是否线程安全？
   • 如果方法内局部变量没有逃离方法的作用范围，它是线程安全的
   • 如果是局部变量引用了对象，并逃离方法的作用范围(m2的形参sb和m3的返回值)，需要考虑线程安全
   • 比如以下代码：

栈内存溢出情况

• 栈帧过多导致栈内存溢出，典型问题：递归调用

• 栈帧过大导致栈内存溢出

堆和栈的区别

难易程度：☆☆☆
出现频率：☆☆☆

组成部分：堆、方法区、栈、本地方法栈、程序计数器

1、堆解决的是对象实例存储的问题，垃圾回收器管理的主要区域。

2、方法区可以认为是堆的一部分，用于存储已被虚拟机加载的信息，常量、静态变量、即时编译器编译后的代码。

3、栈解决的是程序运行的问题，栈里面存的是栈帧，栈帧里面存的是局部变量表、操作数栈、动态链接、方法出口等信息。

4、本地方法栈与栈功能相同，本地方法栈执行的是本地方法，一个Java调用非Java代码的接口。

5、程序计数器（PC寄存器）程序计数器中存放的是当前线程所执行的字节码的行数。JVM工作时就是通过改变这个计数器的值来选取下一个需要执行的字节码指令。

1.5 能不能解释一下方法区？

难易程度：☆☆☆
出现频率：☆☆☆

1.5.1 概述

• 方法区(Method Area)是各个线程共享的内存区域
• 主要存储类的信息、运行时常量池
• 虚拟机启动的时候创建，关闭虚拟机时释放
• 如果方法区域中的内存无法满足分配请求，则会抛出OutOfMemoryError: Metaspace

1.5.2 常量池

可以看作是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息

查看字节码结构（类的基本信息、常量池、方法定义）javap -v xx.class

比如下面是一个Application类的main方法执行，源码如下：

public class Application {public static void main(String[] args) {System.out.println("hello world");}
}

找到类对应的class文件存放目录，执行命令：javap -v Application.class 查看字节码结构

D:\code\jvm-demo\target\classes\com\heima\jvm>javap -v Application.class
Classfile /D:/code/jvm-demo/target/classes/com/heima/jvm/Application.classLast modified 2023-05-07; size 564 bytes    //最后修改的时间MD5 checksum c1b64ed6491b9a16c2baab5061c64f88   //签名Compiled from "Application.java"   //从哪个源码编译
public class com.heima.jvm.Application   //包名，类名minor version: 0major version: 52     //jdk版本flags: ACC_PUBLIC, ACC_SUPER  //修饰符
Constant pool:   //常量池#1 = Methodref          #6.#20         // java/lang/Object."<init>":()V#2 = Fieldref           #21.#22        // java/lang/System.out:Ljava/io/PrintStream;#3 = String             #23            // hello world#4 = Methodref          #24.#25        // java/io/PrintStream.println:(Ljava/lang/String;)V#5 = Class              #26            // com/heima/jvm/Application#6 = Class              #27            // java/lang/Object#7 = Utf8               <init>#8 = Utf8               ()V#9 = Utf8               Code#10 = Utf8               LineNumberTable#11 = Utf8               LocalVariableTable#12 = Utf8               this#13 = Utf8               Lcom/heima/jvm/Application;#14 = Utf8               main#15 = Utf8               ([Ljava/lang/String;)V#16 = Utf8               args#17 = Utf8               [Ljava/lang/String;#18 = Utf8               SourceFile#19 = Utf8               Application.java#20 = NameAndType        #7:#8          // "<init>":()V#21 = Class              #28            // java/lang/System#22 = NameAndType        #29:#30        // out:Ljava/io/PrintStream;#23 = Utf8               hello world#24 = Class              #31            // java/io/PrintStream#25 = NameAndType        #32:#33        // println:(Ljava/lang/String;)V#26 = Utf8               com/heima/jvm/Application#27 = Utf8               java/lang/Object#28 = Utf8               java/lang/System#29 = Utf8               out#30 = Utf8               Ljava/io/PrintStream;#31 = Utf8               java/io/PrintStream#32 = Utf8               println#33 = Utf8               (Ljava/lang/String;)V
{public com.heima.jvm.Application();  //构造方法descriptor: ()Vflags: ACC_PUBLICCode:stack=1, locals=1, args_size=10: aload_01: invokespecial #1                  // Method java/lang/Object."<init>":()V4: returnLineNumberTable:line 3: 0LocalVariableTable:Start  Length  Slot  Name   Signature0       5     0  this   Lcom/heima/jvm/Application;public static void main(java.lang.String[]);  //main方法descriptor: ([Ljava/lang/String;)Vflags: ACC_PUBLIC, ACC_STATICCode:stack=2, locals=1, args_size=10: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;3: ldc           #3                  // String hello world5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V8: returnLineNumberTable:line 7: 0line 8: 8LocalVariableTable:Start  Length  Slot  Name   Signature0       9     0  args   [Ljava/lang/String;
}
SourceFile: "Application.java"

下图，左侧是main方法的指令信息，右侧constant pool 是常量池

main方法按照指令执行的时候，需要到常量池中查表翻译找到具体的类和方法地址去执行

1.5.3 运行时常量池

常量池是 *.class 文件中的，当该类被加载，它的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址

1.6 你听过直接内存吗？

难易程度：☆☆☆
出现频率：☆☆☆

不受 JVM 内存回收管理，是虚拟机的系统内存，常见于 NIO 操作时，用于数据缓冲区，分配回收成本较高，但读写性能高，不受 JVM 内存回收管理

举例：

需求，在本地电脑中的一个较大的文件（超过100m）从一个磁盘挪到另外一个磁盘

代码如下：

/*** 演示 ByteBuffer 作用*/
public class Demo1_9 {static final String FROM = "E:\\编程资料\\第三方教学视频\\youtube\\Getting Started with Spring Boot-sbPSjI4tt10.mp4";static final String TO = "E:\\a.mp4";static final int _1Mb = 1024 * 1024;public static void main(String[] args) {io(); // io 用时：1535.586957 1766.963399 1359.240226directBuffer(); // directBuffer 用时：479.295165 702.291454 562.56592}private static void directBuffer() {long start = System.nanoTime();try (FileChannel from = new FileInputStream(FROM).getChannel();FileChannel to = new FileOutputStream(TO).getChannel();) {ByteBuffer bb = ByteBuffer.allocateDirect(_1Mb);while (true) {int len = from.read(bb);if (len == -1) {break;}bb.flip();to.write(bb);bb.clear();}} catch (IOException e) {e.printStackTrace();}long end = System.nanoTime();System.out.println("directBuffer 用时：" + (end - start) / 1000_000.0);}private static void io() {long start = System.nanoTime();try (FileInputStream from = new FileInputStream(FROM);FileOutputStream to = new FileOutputStream(TO);) {byte[] buf = new byte[_1Mb];while (true) {int len = from.read(buf);if (len == -1) {break;}to.write(buf, 0, len);}} catch (IOException e) {e.printStackTrace();}long end = System.nanoTime();System.out.println("io 用时：" + (end - start) / 1000_000.0);}
}

可以发现，使用传统的IO的时间要比NIO操作的时间长了很多了，也就说NIO的读性能更好。

这个是跟我们的JVM的直接内存是有一定关系，如下图，是传统阻塞IO的数据传输流程

下图是NIO传输数据的流程，在这个里面主要使用到了一个直接内存，不需要在堆中开辟空间进行数据的拷贝，jvm可以直接操作直接内存，从而使数据读写传输更快。

1.7 堆栈的区别是什么？

难易程度：☆☆☆
出现频率：☆☆☆☆

1、栈内存一般会用来存储局部变量和方法调用，但堆内存是用来存储Java对象和数组的。堆会GC垃圾回收，而栈不会。

2、栈内存是线程私有的，而堆内存是线程共有的。

3,、两者异常错误不同，但如果栈内存或者堆内存不足都会抛出异常。

栈空间不足：java.lang.StackOverFlowError。

堆空间不足：java.lang.OutOfMemoryError。

2 类加载器

2.1 什么是类加载器，类加载器有哪些?

难易程度：☆☆☆☆
出现频率：☆☆☆

想理解类加载器，务必要先清楚对于一个Java文件，它从编译到执行的整个过程。

• 类加载器：用于装载字节码文件(.class文件)
• 运行时数据区：用于分配存储空间
• 执行引擎：执行字节码文件或本地方法
• 垃圾回收器：用于对JVM中的垃圾内容进行回收

类加载器

JVM只会运行二进制文件，而类加载器（ClassLoader）的主要作用就是将字节码文件加载到JVM中，从而让Java程序能够启动起来。现有的类加载器基本上都是java.lang.ClassLoader的子类，该类的主要职责就是用于将指定的类找到或生成对应的字节码文件，同时类加载器还会负责加载程序所需要的资源

类加载器种类

类加载器根据各自加载范围的不同，划分为四种类加载器：

• 启动类加载器(BootStrap ClassLoader)：

该类并不继承ClassLoader类，其是由C++编写实现。用于加载JAVA_HOME/jre/lib目录下的类库。

• 扩展类加载器(ExtClassLoader)：

该类是ClassLoader的子类，主要加载JAVA_HOME/jre/lib/ext目录中的类库。

• 应用类加载器(AppClassLoader)：

该类是ClassLoader的子类，主要用于加载classPath下的类，也就是加载开发者自己编写的Java类。

• 自定义类加载器：

开发者自定义类继承ClassLoader，实现自定义类加载规则。

上述三种类加载器的层次结构如下如下：

类加载器的体系并不是“继承”体系，而是委派体系，类加载器首先会到自己的parent中查找类或者资源，如果找不到才会到自己本地查找。类加载器的委托行为动机是为了避免相同的类被加载多次。

2.2 什么是双亲委派模型？

难易程度：☆☆☆☆
出现频率：☆☆☆☆

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就返回成功；只有父类加载器无法完成此加载任务时，才由下一级去加载。

2.3 JVM为什么采用双亲委派机制

难易程度：☆☆☆
出现频率：☆☆☆

（1）通过双亲委派机制可以避免某一个类被重复加载，当父类已经加载后则无需重复加载，保证唯一性。

（2）为了安全，保证类库API不会被修改

在工程中新建java.lang包，接着在该包下新建String类，并定义main函数

public class String {public static void main(String[] args) {System.out.println("demo info");}
}

此时执行main函数，会出现异常，在类 java.lang.String 中找不到 main 方法

出现该信息是因为由双亲委派的机制，java.lang.String的在启动类加载器(Bootstrap classLoader)得到加载，因为在核心jre库中有其相同名字的类文件，但该类中并没有main方法。这样就能防止恶意篡改核心API库。

拓展：如何打破双亲委派机制

b站看到的面试题大三文科生自学Java, 看看面试中回答的怎么样？ 24届秋招记录，再接再厉_哔哩哔哩_bilibili

方法一：Java提供的线程上下文类加载器（默认赋值应用类加载器赋值给线程上下文类加载器），jdbc对数据库驱动的加载就是一种打破双亲委派机制，

方法二：自己写一个类加载器，重写load class向上递归的方法

2.4 说一下类装载的执行过程？

难易程度： ☆☆☆☆☆
出现频率：☆☆☆

类从加载到虚拟机中开始，直到卸载为止，它的整个生命周期包括了：加载、验证、准备、解析、初始化、使用和卸载这7个阶段。其中，验证、准备和解析这三个部分统称为连接（linking）。

类加载过程详解

1.加载

• 通过类的全名，获取类的二进制数据流。
• 解析类的二进制数据流为方法区内的数据结构（Java类模型）
• 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

2.验证

验证类是否符合JVM规范，安全性检查

(1)文件格式验证:是否符合Class文件的规范

(2)元数据验证

这个类是否有父类（除了Object这个类之外，其余的类都应该有父类）

这个类是否继承（extends）了被final修饰过的类（被final修饰过的类表示类不能被继承）

类中的字段、方法是否与父类产生矛盾。（被final修饰过的方法或字段是不能覆盖的）

(3)字节码验证

主要目的是通过对数据流和控制流的分析，确定程序语义是合法的、符合逻辑的。

(4)符号引用验证：

符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量

比如：int i = 3;
字面量：3
符号引用：i

3.准备

为类变量分配内存并设置类变量初始值

• static变量，分配空间在准备阶段完成（设置默认值），赋值在初始化阶段完成
• static变量是final的基本类型，以及字符串常量，值已确定，赋值在准备阶段完成
• static变量是final的引用类型，那么赋值也会在初始化阶段完成

4.解析

把类中的符号引用转换为直接引用

比如：方法中调用了其他方法，方法名可以理解为符号引用，而直接引用就是使用指针直接指向方法。

5.初始化

对类的静态变量，静态代码块执行初始化操作

• 如果初始化一个类的时候，其父类尚未初始化，则优先初始化其父类。
• 如果同时包含多个静态变量和静态代码块，则按照自上而下的顺序依次执行。

6.使用

JVM 开始从入口方法开始执行用户的程序代码

• 调用静态类成员信息（比如：静态字段、静态方法）
• 使用new关键字为其创建对象实例

7.卸载

当用户程序代码执行完毕后，JVM 便开始销毁创建的 Class 对象，最后负责运行的 JVM 也退出内存