虚拟机栈
# 虚拟机栈概述
最推荐看的还是官方对虚拟机栈的说明:Chapter 2. The Structure of the Java Virtual Machine (oracle.com) (opens new window)
# 背景
由于跨平台性的设计,Java 的指令都是根据栈来设计的。不同平台 CPU 架构不同,所以不能设计为基于寄存器的。
优点是跨平台,指令集小,编译器容易实现,缺点是性能下降,实现同样的功能需要更多的指令。
笔记
比较详细的优缺点说明:
优点
- 平台独立性:
- Java 的一个核心目标是实现跨平台兼容性,即 “一次编写,到处运行”。基于栈的虚拟机更容易在不同的硬件和操作系统上实现,因为它不依赖于特定的硬件架构(如寄存器的数量和类型)。
- 基于寄存器的设计通常会依赖于特定硬件的特性,这可能会影响代码在不同平台上的可移植性。
- 简化虚拟机的实现:
- 基于栈的虚拟机(如 Java 虚拟机)相对于基于寄存器的虚拟机来说,实现起来更为简单和直接。栈机制本质上提供了一个明确的操作顺序和一个集中的数据管理点,这简化了指令集的设计。
- 基于寄存器的虚拟机通常需要复杂的寄存器分配算法和优化策略,这在虚拟环境中实现起来相对困难。
- 代码紧凑性:
- 基于栈的指令通常比基于寄存器的指令更小,因为它们不需要指定寄存器的地址。这使得 Java 字节码更加紧凑,减少了程序的大小。
- 紧凑的代码意味着更小的内存占用和更快的网络传输,这对于 Java 最初的设计目标 —— 在网络上高效传输代码 —— 是非常重要的。
- 优化的灵活性:
- Java 的设计哲学是将性能优化留给 JVM 的实现,而不是由程序员或源代码来处理。基于栈的指令集允许 JVM 在运行时进行更多的优化,如即时编译(JIT)和高级的垃圾收集。
- 在 JVM 层面进行优化意味着可以根据目标平台的具体情况进行调整,而不需要改变 Java 程序代码。
- 平台独立性:
缺点
- 性能开销:
- 基于栈的虚拟机可能在执行时效率上不如基于寄存器的虚拟机。因为在栈机中,操作通常涉及对栈的频繁访问和修改,这可能导致比在寄存器中直接操作更高的指令执行开销。
- 每次操作都需要将数据推送到栈中或从栈中弹出,这增加了指令数量和执行时间。
- 更多的内存访问:
- 基于栈的指令集可能导致更多的内存访问操作,因为数据需要不断地从内存推入栈中,然后再从栈中取出。这与基于寄存器的系统相比,后者可以更频繁地在寄存器之间直接进行操作,减少访问内存的次数。
- 优化限制:
- 虽然基于栈的设计让 Java 虚拟机在运行时有更多优化的空间,但这种设计本身可能对某些底层优化构成限制。例如,在寄存器分配和指令调度方面,基于寄存器的架构可能提供更多的优化机会。
- 指令集大小:
- 基于栈的虚拟机的指令集可能比基于寄存器的更大。虽然单个指令更紧凑,但完成同样的操作可能需要更多的指令。这可能导致程序的整体大小增加,尽管每条指令本身较小。
- 复杂的 JIT 编译器:
- 为了提高基于栈的虚拟机的执行效率,通常需要更复杂的即时编译器(JIT)来进行优化。这增加了虚拟机实现的复杂性。
- 性能开销:
# 打破固有印象
有不少 Java 开发人员一提到 Java 内存结构,就会非常粗粒度地将 JVM 中的内存区理解为仅有 Java 堆 (heap) 和栈 (stack)?为什么?
Java 开发人员在讨论 Java 内存结构时经常提及 Java 堆(Heap)和 Java 栈(Stack),可能是因为这两部分在日常开发中最为显著和直接相关。不过,JVM 的内存模型实际上更为复杂,包括多个部分。让我们先探讨为什么开发人员倾向于主要关注堆和栈,然后简要概述 JVM 的完整内存结构。
为什么主要关注堆和栈
- 直接与代码相关:
- 开发人员在编写 Java 程序时,直接与堆和栈进行交互。对象存储在堆上,而方法的局部变量和调用存储在栈上。
- 这种直接关联使得对堆和栈的理解和管理成为日常开发的重要组成部分。
- 常见的性能问题:
- 内存泄漏和内存溢出通常发生在堆上,因为这是对象分配和垃圾回收的地方。
- 栈通常涉及线程执行和方法调用的问题,如栈溢出错误。
- 调优重点:
- 性能调优和资源管理经常集中在堆内存管理上,因为它关系到应用的可扩展性和稳定性。
JVM 的完整内存结构
除了堆和栈,JVM 的内存模型还包括几个其他重要部分:
- 方法区(Method Area):
- 存储类信息、常量、静态变量等。在某些 JVM 实现中,这部分被称为永久代(PermGen)或元空间(Metaspace)。
- 程序计数器(Program Counter Register):
- 每个线程都有自己的程序计数器,它指示当前线程执行的字节码指令位置。
- 本地方法栈(Native Method Stack):
- 专门用于管理本地方法的调用。
- 堆(Heap):
- 用于存储对象实例和数组,是垃圾回收的主要区域。
- 栈(Stack):
- 存储局部变量、操作数栈、方法调用等,每个线程有自己的栈。
# 内存中的堆与栈
栈是运行时的单位,而堆是存储的单位。
即:栈解决程序的运行问题,即程序如何执行,或者说如何处理数据。堆解决的是数据存储的问题,即数据怎么放、放在哪儿。
# 虚拟机栈的基本内容
# Java 虚拟机栈是什么?
Java 虚拟机栈(Java Virtual Machine Stack),早期也叫 Java 栈。每个线程在创建时都会创建一个虚拟机栈,其内部保存一个个的栈帧(Stack Frame),对应着一次次的 Java 方法调用。
栈是线程私有的。
public class StackTest {
public static void main(String[] args) {
StackTest test = new StackTest();
test.methodA();
}
public void methodA() {
int i = 10;
int j = 20;
methodB();
}
public void methodB() {
int k = 30;
int m = 40;
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 生命周期
生命周期和线程一致,也就是线程结束了,该虚拟机栈也销毁了
# 作用
- 主管 Java 程序的运行,它保存方法的局部变量(8 种基本数据类型、对象的引用地址)、部分结果,并参与方法的调用和返回。
- 局部变量,它是相比于成员变量来说的(或属性)
- 基本数据类型变量 VS 引用类型变量(类、数组、接口)
# 虚拟机栈的特点
- 栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器。
- JVM 直接对 Java 栈的操作只有两个:
- 每个方法执行,伴随着进栈(入栈、压栈)。
- 执行结束后的出栈工作。
- 对于栈来说不存在垃圾回收问题
- 栈不需要 GC,但是可能存在 OOM。
# 面试题:栈中可能出现的异常?
Java 虚拟机规范允许 Java 栈的大小是动态的或者是固定不变的。
固定:每一个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量,Java 虚拟机将会抛出一个 StackoverflowError 异常。
/** * 演示栈中的异常:StackOverflowError */ public class StackErrorTest { // 自己调用自己 public static void main(String[] args) { main(args); } }
1
2
3
4
5
6
7
8
9
动态:在尝试扩展的时候无法申请到足够的内存,或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈,那 Java 虚拟机将会抛出一个 OutofMemoryError 异常。
- 这个代码不好演示,需要自己把自己电脑内存弄快满,然后才能出现这个异常。
# 设置栈内存大小
-Xss size
设置线程堆栈大小(以字节为单位) k
或 K
表示 KB, m
或 M
表示 MB,以及 g
或 G
表示 GB 价值取决于平台:
- Linux/x64(64 位):1024 KB
- macOS(64 位):1024 KB
- Oracle Solaris/x64(64 位):1024 KB
- Windows:默认值取决于虚拟记忆
以下示例以不同的单位将线程堆栈大小设置为 1024 KB:
-Xss1m
-Xss1024k
-Xss1048576
2
3
此选项类似于 -XX:ThreadStackSize
。
/**
* 默认情况下:count : 11414
* 设置栈的大小: -Xss256k : count : 2459
*/
public class StackErrorTest {
private static int count = 1;
public static void main(String[] args) {
System.out.println(count);
count++;
main(args);
}
}
2
3
4
5
6
7
8
9
10
11
12
13
IDEA 中可以按以下设置,如果是老版本 IDEA,请自行百度。
# 栈的存储单位
# 栈中存储什么?
- 每个线程都有自己的栈,栈中的数据都是以栈帧(Stack Frame)的格式存在。
- 在这个线程上正在执行的每个方法都各自对应一个栈帧(Stack Frame)。
- 栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息。
# 栈运行原理
JVM 直接对 Java 栈的操作只有两个,就是对栈帧的压栈和出栈,遵循先进后出 / 后进先出原则。
在一条活动线程中,一个时间点上,只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的。这个栈帧被称为当前栈帧(Current Frame),与当前栈帧相对应的方法就是当前方法(Current Method),定义这个方法的类就是当前类(Current Class)。
执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
如果在该方法中调用了其他方法,对应的新的栈帧会被创建出来,放在栈的顶端,成为新的当前帧。
不同线程中所包含的栈帧是不允许存在相互引用的,即不可能在一个栈帧之中引用另外一个线程的栈帧。
如果当前方法调用了其他方法,方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧。
Java 方法有两种返回函数的方式。一种是正常的函数返回,使用 return 指令;另一种是方法执行中出现未捕获处理的异常,以抛出异常的方式结束;但不管使用哪种方式,都会导致栈帧被弹出。
/** * 方法的结束方式分为两种: * ① 正常结束,以 return 为代表 * ② 方法执行中出现未捕获处理的异常,以抛出异常的方式结束 * */ public class StackFrameTest { public static void main(String[] args) { try { StackFrameTest test = new StackFrameTest(); test.method1(); } catch (Exception e) { e.printStackTrace(); } System.out.println("main()正常结束"); } public void method1() { System.out.println("method1()开始执行..."); method2(); System.out.println("method1()执行结束..."); // System.out.println(10 / 0); // return ;//可以省略 } public int method2() { System.out.println("method2()开始执行..."); int i = 10; int m = (int) method3(); System.out.println("method2()即将结束..."); return i + m; } public double method3() { System.out.println("method3()开始执行..."); double j = 20.0; System.out.println("method3()即将结束..."); return j; } }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# 栈桢的内部结构
每个栈帧中存储着:
- 局部变量表(Local Variables)。
- 操作数栈(Operand Stack)(或表达式栈)。
- 动态链接(Dynamic Linking)(或指向运行时常量池的方法引用)。
- 方法返回地址(Return Address)(或方法正常退出或者异常退出的定义)。
- 一些附加信息。
行每个线程下的栈都是私有的,因此每个线程都有自己各自的栈,并且每个栈里面都有很多栈帧,栈帧的大小主要由局部变量表和操作数栈决定的。
# 局部变量表
# 概念
局部变量表也被称之为局部变量数组或本地变量表。
定义为一个数字数组,主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型、对象引用(reference),以及 returnAddress 返回值类型。
由于局部变量表是建立在线程的栈上,是线程的私有数据,因此不存在数据安全问题。
局部变量表所需的容量大小是在编译期确定下来的,并保存在方法的 Code 属性的 maximum local variables 数据项中。在方法运行期间是不会改变局部变量表的大小的。
方法嵌套调用的次数由栈的大小决定。一般来说,栈越大,方法嵌套调用次数越多。对一个函数而言,它的参数和局部变量越多,使得局部变量表膨胀,它的栈帧就越大,以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间,导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。在方法执行时,虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后,随着方法栈帧的销毁,局部变量表也会随之销毁。
# 字节码解释
//完整代码
public class LocalVariablesTest {
private int count = 0;
//关于 Slot 的使用的理解
public LocalVariablesTest() {
this.count = 1;
}
public static void main(String[] args) {
LocalVariablesTest test = new LocalVariablesTest();
int num = 10;
test.test1();
}
//练习:
public static void testStatic() {
LocalVariablesTest test = new LocalVariablesTest();
Date date = new Date();
int count = 10;
System.out.println(count);
//因为 this 变量不存在于当前方法的局部变量表中!!
// System.out.println(this.count);
}
public void test1() {
Date date = new Date();
String name1 = "atguigu.com";
test2(date, name1);
System.out.println(date + name1);
}
public String test2(Date dateP, String name2) {
dateP = null;
name2 = "songhongkang";
double weight = 130.5;//占据两个 slot
char gender = '男';
return dateP + name2;
}
public void test3() {
this.count++;
}
public void test4() {
int a = 0;
{
int b = 0;
b = a + 1;
}
//变量 c 使用之前已经销毁的变量 b 占据的 slot 的位置
int c = a + 1;
}
/*
变量的分类:按照数据类型分:① 基本数据类型 ② 引用数据类型
按照在类中声明的位置分:① 成员变量:在使用前,都经历过默认初始化赋值
类变量: linking 的 prepare 阶段:给类变量默认赋值 ---> initial 阶段:给类变量显式赋值即静态代码块赋值
实例变量:随着对象的创建,会在堆空间中分配实例变量空间,并进行默认赋值
② 局部变量:在使用前,必须要进行显式赋值的!否则,编译不通过
*/
public void test5Temp() {
int num;
//System.out.println(num);//错误信息:变量 num 未进行初始化
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
# 访问标志、字节码、异常、杂项
# 本地变量表、行号表
Java 代码的行号和字节码指令行号的对应关系。
局部变量表所需的容量大小是在编译期确定下来的。
起始 PC 表示在字节码的 11 行开始生效,11 行字节码对应的是 20 行 Java 代码,而第 20 行是 test.test1 () 说明是从声明的下一行开始生效。
长度为 5 表示局部变量剩余有效行数,main 方法字节码指令总共有 16 行,从 11 行开始生效,那么剩下就是 16-11=5。
# 关于 Slot 的理解
参数值的存放总是从局部变量数组索引 0 的位置开始,到数组长度 - 1 的索引结束。
局部变量表,最基本的存储单元是 Slot(变量槽),局部变量表中存放编译期可知的各种基本数据类型(8 种),引用类型(reference),returnAddress 类型的变量。
在局部变量表里,32 位以内的类型只占用一个 slot(包括 returnAddress 类型),64 位的类型占用两个 slot(long 和 double)。
byte、short、char 在储存前被转换为 int,boolean 也被转换为 int,0 表示 false,非 0 表示 true。
long 和 double 则占据两个 slot。
JVM 会为局部变量表中的每一个 Slot 都分配一个访问索引,通过这个索引即可成功访问到局部变量表中指定的局部变量值。
当一个实例方法被调用的时候,它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个 slot 上。
如果需要访问局部变量表中一个 64bit 的局部变量值时,只需要使用前一个索引即可。(比如:访问 long 或 double 类型变量)。
如果当前帧是由构造方法或者实例方法创建的,那么该对象引用 this 将会存放在 index 为 0 的 slot 处,其余的参数按照参数表顺序继续排列。(this 也相当于一个变量)。
索引 | 类型 | 参数 |
---|---|---|
0 | int | int k |
1 | long | long m |
3 | float | float p |
4 | double | double q |
6 | reference | Object t |
# 该对象引用 this 将会存放在 index 为 0 的 slot 处
public void test3() {
this.count++;
}
2
3
局部变量表:this 存放在 index = 0 的位置。
# 64 位的类型(long 和 double)占用两个 slot
public String test2(Date dateP, String name2) {
dateP = null;
name2 = "songhongkang";
double weight = 130.5;//占据两个 slot
char gender = '男';
return dateP + name2;
}
2
3
4
5
6
7
# 不能在静态方法中使用 this
代码就不展示,因为会报错,至于为什么不能在静态方法中使用 this
,原因是静态方法不属于任何实例对象,而是属于类本身。因此,在静态方法的上下文中没有 this
引用,因为 this
指的是当前对象的引用,而静态方法调用时不需要任何对象实例。换句话说,没有 this
因为没有当前对象的概念存在。
# Slot 的重复利用
栈帧中的局部变量表中的槽位是可以重用的,如果一个局部变量过了其作用域,那么在其作用域之后申明新的局部变量变就很有可能会复用过期局部变量的槽位,从而达到节省资源的目的。
public void test4() {
int a = 0; // 'a' 使用了 slot 1,记住非 static 方法的 slot 0 永远都是 this
{
int b = 0; // 'b' 使用了 slot 2
b = a + 1;
} //'b'的范围到此为止,所以它的槽可以重用。
int c = a + 1; // 'c' 使用了 slot 2
}
2
3
4
5
6
7
8
笔记
a
是在方法的开始就声明的,所以它会使用局部变量表中的第一个槽位(注意,第 0 个槽位总是用于存储this
引用,因为这是非静态方法)。b
是在一个新的作用域内声明的。这个作用域是由大括号{}
定义的。在这个作用域内,b
使用了下一个可用的槽位,即第二个槽位。- 当离开
b
的作用域(即执行流离开了包含b
声明的大括号),b
的生命周期就结束了。这意味着b
占用的槽位不再需要保留b
的值,因为b
不再能被访问到了。 - 然后声明了变量
c
。因为b
的槽位现在是空的,c
可以使用这个槽位。这就是为什么c
也被放在了槽位 2。
# 变量的分类
- 按照数据类型
- 基本数据类型。
- 引用数据类型。
- 按照在类中声明的位置
- 成员变量:在使用前,都经历过默认初始化赋值.
- 类变量: linking 的 prepare 阶段:给类变量默认赋值 ---> initial 阶段:给类变量显式赋值即静态代码块赋值。
- 实例变量:随着对象的创建,会在堆空间中分配实例变量空间,并进行默认赋值。
- 局部变量:在使用前,必须要进行显式赋值的!否则,编译不通过。
- 成员变量:在使用前,都经历过默认初始化赋值.
# 静态变量与局部变量的对比
- 参数表分配完毕之后,再根据方法体内定义的变量的顺序和作用域分配。
- 我们知道成员变量有两次初始化的机会,第一次是在 “准备阶段”,执行系统初始化,对类变量设置零值,另一次则是在 “初始化” 阶段,赋予程序员在代码中定义的初始值。
- 和类变量初始化不同的是,局部变量表不存在系统初始化的过程,这意味着一旦定义了局部变量则必须人为的初始化,否则无法使用。
# 补充说明
- 在栈帧中,与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时,虚拟机使用局部变量表完成方法的传递。
- 局部变量表中的变量也是重要的垃圾回收根节点,只要被局部变量表中直接或间接引用的对象都不会被回收。
# 操作数栈
# 操作数栈的特性
每一个独立的栈帧除了包含局部变量表以外,还包含一个后进先出(Last - In - First -Out)的 操作数栈,也可以称之为表达式栈(Expression Stack)。
操作数栈,在方法执行过程中,根据字节码指令,往栈中写入数据或提取数据,即入栈(push)和 出栈(pop)。
某些字节码指令将值压入操作数栈,其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。
比如:执行复制、交换、求和等操作。
# 概述
操作数栈,主要用于保存计算过程的中间结果,同时作为计算过程中变量临时的存储空间。
操作数栈就是 JVM 执行引擎的一个工作区,当一个方法刚开始执行的时候,一个新的栈帧也会随之被创建出来,这时方法的操作数栈是空的。
每一个操作数栈都会拥有一个明确的栈深度用于存储数值,其所需的最大深度在编译期就定义好了,保存在方法的 Code 属性中,为 maxstack 的值。
栈中的任何一个元素都是可以任意的 Java 数据类型。
- 32bit 的类型占用一个栈单位深度。
- 64bit 的类型占用两个栈单位深度。
操作数栈并非采用访问索引的方式来进行数据访问的,而是只能通过标准的入栈和出栈操作来完成一次数据访问。只不过操作数栈是用数组这个结构来实现的而已。
如果被调用的方法带有返回值的话,其返回值将会被压入当前栈帧的操作数栈中,并更新 PC 寄存器中下一条需要执行的字节码指令。
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配,这由编译器在编译器期间进行验证,同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
另外,我们说 Java 虚拟机的解释引擎是基于栈的执行引擎,其中的栈指的就是操作数栈。
# 代码追踪
# 逐步观察
public void testAddOperation() {
//byte、short、char、boolean:都以 int 型来保存
byte i = 15;
int j = 8;
int k = i + j;
// int m = 800;
}
2
3
4
5
6
7
步骤一:首先执行第一条语句,PC 寄存器指向的是 0,也就是指令地址为 0,然后使用 bipush 让操作数 15 入操作数栈。
步骤二:执行完后,PC 寄存器往下移,指向下一行代码,下一行代码就是将操作数栈的元素存储到局部变量表 1 的位置(istore_1),我们可以看到局部变量表的已经增加了一个元素。并且操作数栈为空了。
步骤三:然后 PC 下移,指向的是下一行。让操作数 8 也入栈,同时执行 store 操作,存入局部变量表中。
步骤四:然后从局部变量表中,依次将数据放在操作数栈中,等待执行 add 操作。
步骤五:然后将操作数栈中的两个元素执行相加操作,并存储在局部变量表 3 的位置。
# 数值范围和类型
在上面的字节码指令里可以看到,int j = 8 对应的字节码指令却是 bipush 8,但 bipush 不是 byte 类型的 jvm 指令吗?
这是因为在编译时,Java 编译器会尽可能选择更有效、更节省空间的指令。
iconst_<i>
:- 范围:-1 到 5
- 描述:这些指令用于将 int 类型的常量(-1, 0, 1, 2, 3, 4, 5)直接压入栈顶。每个数字都有对应的指令(如
iconst_0
是将 0 推入栈)。
bipush
:- 范围:-128 到 127
- 描述:用于将一个字节(byte)范围内的立即数(即直接指定的数)推送至栈顶。
sipush
:- 范围:-32768 到 32767
- 描述:用于将一个短整型(short)范围内的立即数推送至栈顶。
ldc
:- 范围:整个 int 范围
- 描述:用于从运行时常量池中加载一个 32-bit 常量(int、float 或 String 实例等)到栈顶。对于超过
sipush
能处理的 int 类型数值,就会用到ldc
。
ldc2_w
:- 范围:整个 long 或 double 范围
- 描述:这个指令类似于
ldc
,但用于加载 64-bit 的常量(如 long 和 double 类型数值)到栈顶。
# 栈顶缓存技术
栈顶缓存技术(Top Of Stack Caching)是一种在处理器设计中使用的优化技术,这种技术的目的是减少访问内存的次数,从而提高执行速度。寄存器的主要优点:指令更少,执行速度快,但是指令集(也就是指令种类)很多。
# 栈顶缓存技术的概念
- 基本原理: 栈顶缓存技术的基本原理是将栈顶的几个元素(通常是操作数栈的顶部元素)保留在 CPU 的寄存器中,而不是在内存中的栈结构里。由于 CPU 寄存器的访问速度远快于内存,这样可以显著提高处理速度。
- 与 JVM 的关联: 在 JVM 中,Java 字节码的执行大量依赖于操作数栈。例如,大多数的算术和逻辑操作都是在操作数栈的顶部进行的。通过在 CPU 层面缓存栈顶元素,可以减少对内存栈的访问,从而加快字节码的执行。
# 栈顶缓存技术的优势
- 减少内存访问:由于栈操作是极其频繁的,栈顶缓存可以显著减少内存访问次数,提高执行效率。
- 加快指令执行:处理器可以更快地执行操作,因为它们可以直接在寄存器上进行,而不是在内存中的栈上。
- 提高能效:减少内存访问也意味着降低能耗,这在移动设备和嵌入式系统中尤为重要。
# 栈顶缓存技术的挑战
- 寄存器的限制:寄存器的数量是有限的,这限制了可以缓存的栈顶元素的数量。
- 上下文切换开销:在进行线程或进程上下文切换时,缓存在寄存器中的栈顶元素需要被保存和恢复,这可能会带来额外的开销。
# 动态链接
动态链接(或指向运行时常量池的方法引用)
# 栈帧中的运行时常量池引用
# 栈帧
Java 虚拟机执行方法时,每个方法都会创建一个栈帧(Strack Frame),它包含局部变量表、操作数栈、动态链接信息等。每个栈帧相当于一个线程。
# 运行时常量池引用
每个栈帧中都包含一个指向运行时常量池(Runtime Constant Pool)中该栈帧所属方法的引用。这个运行时常量池是每个类或接口的常量池的运行时表示形式,包含了各种类型的常量,如文字字符串、类引用、字段引用、方法引用等。
# 动态链接的目的
包含运行时常量池引用的目的是为了支持当前方法的代码实现动态链接。例如,当一个方法需要调用另一个方法时,调用指令(如 invokevirtual
, invokespecial
, invokestatic
, invokedynamic
)会使用到这个引用。
# 符号引用到直接引用的转换
# 编译时符号引用
在 Java 源代码被编译成字节码文件时,所有的变量和方法引用被存储为符号引用(Symbolic References)在类文件的常量池中。符号引用是一种抽象的表示,如一个全限定名(Fully Qualified Name)。
# 动态链接的作用
动态链接的作用是在运行时将这些符号引用转换为调用方法的直接引用。这个过程涉及查找正确的方法或字段在内存中的地址,并替换原先的符号引用。
# invokedynamic 指令
invokedynamic
指令特别用于支持 "动态类型语言" 的特性。这个指令允许运行时动态解析方法调用,而不是在编译时静态确定。这对于支持非 Java 语言(如 Groovy 或 Scala)在 JVM 上的运行至关重要。
# 代码示例
public class DynamicLinkingTest {
int num = 10;
public void methodA(){
System.out.println("methodA()....");
}
public void methodB(){
System.out.println("methodB()....");
methodA();
num++;
}
}
2
3
4
5
6
7
8
9
10
11
12
Classfile /C:/Users/XXX/tools/target/classes/com/dfd/jvm/chapter05/java1/DynamicLinkingTest.class
Last modified 2024-1-2; size 732 bytes
MD5 checksum bb354aa83ab19053390aaa51f7fe8c39
Compiled from "DynamicLinkingTest.java"
public class com.dfd.jvm.chapter05.java1.DynamicLinkingTest
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #9.#23 // java/lang/Object."<init>":()V
#2 = Fieldref #8.#24 // com/dfd/jvm/chapter05/java1/DynamicLinkingTest.num:I
#3 = Fieldref #25.#26 // java/lang/System.out:Ljava/io/PrintStream;
#4 = String #27 // methodA()....
#5 = Methodref #28.#29 // java/io/PrintStream.println:(Ljava/lang/String;)V
#6 = String #30 // methodB()....
#7 = Methodref #8.#31 // com/dfd/jvm/chapter05/java1/DynamicLinkingTest.methodA:()V
#8 = Class #32 // com/dfd/jvm/chapter05/java1/DynamicLinkingTest
#9 = Class #33 // java/lang/Object
#10 = Utf8 num
#11 = Utf8 I
#12 = Utf8 <init>
#13 = Utf8 ()V
#14 = Utf8 Code
#15 = Utf8 LineNumberTable
#16 = Utf8 LocalVariableTable
#17 = Utf8 this
#18 = Utf8 Lcom/dfd/jvm/chapter05/java1/DynamicLinkingTest;
#19 = Utf8 methodA
#20 = Utf8 methodB
#21 = Utf8 SourceFile
#22 = Utf8 DynamicLinkingTest.java
#23 = NameAndType #12:#13 // "<init>":()V
#24 = NameAndType #10:#11 // num:I
#25 = Class #34 // java/lang/System
#26 = NameAndType #35:#36 // out:Ljava/io/PrintStream;
#27 = Utf8 methodA()....
#28 = Class #37 // java/io/PrintStream
#29 = NameAndType #38:#39 // println:(Ljava/lang/String;)V
#30 = Utf8 methodB()....
#31 = NameAndType #19:#13 // methodA:()V
#32 = Utf8 com/dfd/jvm/chapter05/java1/DynamicLinkingTest
#33 = Utf8 java/lang/Object
#34 = Utf8 java/lang/System
#35 = Utf8 out
#36 = Utf8 Ljava/io/PrintStream;
#37 = Utf8 java/io/PrintStream
#38 = Utf8 println
#39 = Utf8 (Ljava/lang/String;)V
{
int num;
descriptor: I
flags:
public com.dfd.jvm.chapter05.java1.DynamicLinkingTest();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 10
7: putfield #2 // Field num:I
10: return
LineNumberTable:
line 7: 0
line 9: 4
LocalVariableTable:
Start Length Slot Name Signature
0 11 0 this Lcom/dfd/jvm/chapter05/java1/DynamicLinkingTest;
public void methodA();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #4 // String methodA()....
5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
LineNumberTable:
line 12: 0
line 13: 8
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 this Lcom/dfd/jvm/chapter05/java1/DynamicLinkingTest;
public void methodB();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=1, args_size=1
0: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #6 // String methodB()....
5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: aload_0
9: invokevirtual #7 // Method methodA:()V
12: aload_0
13: dup
14: getfield #2 // Field num:I
17: iconst_1
18: iadd
19: putfield #2 // Field num:I
22: return
LineNumberTable:
line 16: 0
line 18: 8
line 20: 12
line 21: 22
LocalVariableTable:
Start Length Slot Name Signature
0 23 0 this Lcom/dfd/jvm/chapter05/java1/DynamicLinkingTest;
}
SourceFile: "DynamicLinkingTest.java"
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
查看 methodB 方法的字节码文件,其中使用到了调用指令 invokevirtual,但是后面的 #7 是什么意思?
- #7
- 看字节码的 Constant pool 部分中 #7 的定义是一个 Methodref(方法引用)。
- 其值为 #8.#31。
- #8
#8 = Class #32
:去找 #32。#32 = com/dfd/jvm/chapter05/java1/DynamicLinkingTest
。
- 结论:通过 #8 我们找到了
DynamicLinkingTest
这个类。
- #31
#31 = NameAndType #19:#13
:去找 #19 和 #13。#19 = Utf8 methodA
:方法名为 methodA。#13 = Utf8 ()V
:方法没有形参,返回值为 void。
结论:通过 #7 我们就能找到需要调用的 methodA () 方法,并进行调用。
# 执行流程
为什么要用常量池呢?
- 因为在不同的方法,都可能调用常量或者方法,所以只需要存储一份即可,然后记录其引用即可,节省了空间。
- 常量池的作用:就是为了提供一些符号和常量,便于指令的识别。
# 方法的调用:解析和分派
# 静态链接与动态链接
在 JVM 中,将符号引用转换为调用方法的直接引用与方法的绑定机制相关。
# 静态链接
当一个字节码文件被装载进 JVM 内部时,如果被调用的目标方法在编译期确定,且运行期保持不变时,这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接。
# 动态链接
如果被调用的方法在编译期无法被确定下来,也就是说,只能够在程序运行期将调用的方法的符号转换为直接引用,由于这种引用转换过程具备动态性,因此也被称之为动态链接。
# 早期绑定与晚期绑定
静态链接和动态链接对应的方法的绑定机制为:早期绑定(Early Binding)和晚期绑定(Late Binding)。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程,这仅仅发生一次。
# 早期绑定
早期绑定就是指被调用的目标方法如果在编译期可知,且运行期保持不变时,即可将这个方法与所属的类型进行绑定,这样一来,由于明确了被调用的目标方法究竟是哪一个,因此也就可以使用静态链接的方式将符号引用转换为直接引用。
# 晚期绑定
如果被调用的方法在编译期无法被确定下来,只能够在程序运行期根据实际的类型绑定相关的方法,这种绑定方式也就被称之为晚期绑定。
注意
早期绑定与晚期绑定主要涉及编程语言的类型系统和方法调用机制,关注的是如何处理对象和方法。而静态链接与动态链接则关注于程序的构建过程,特别是如何处理和包含外部库和模块。
class Animal {
public void eat() {
System.out.println("动物进食");
}
}
interface Huntable {
void hunt();
}
class Dog extends Animal implements Huntable {
@Override
public void eat() {
System.out.println("狗吃骨头");
}
@Override
public void hunt() {
System.out.println("捕食耗子,多管闲事");
}
}
class Cat extends Animal implements Huntable {
public Cat() {
super();//表现为:早期绑定
}
public Cat(String name) {
this();//表现为:早期绑定
}
@Override
public void eat() {
super.eat();//表现为:早期绑定
System.out.println("猫吃鱼");
}
@Override
public void hunt() {
System.out.println("捕食耗子,天经地义");
}
}
public class AnimalTest {
public void showAnimal(Animal animal) {
animal.eat();//表现为:晚期绑定
}
public void showHunt(Huntable h) {
h.hunt();//表现为:晚期绑定
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
invokevirtual
- 描述:
invokevirtual
指令用于调用对象的实例方法,基于对象的实际类型。 - 晚期绑定:这确实体现了晚期绑定(或动态绑定),因为具体调用的方法实现是在运行时,基于对象的实际类型确定的。这支持了多态性,允许子类重写父类方法。
invokeinterface
- 描述:
invokeinterface
用于调用接口方法。 - 晚期绑定:这同样体现了晚期绑定。接口方法的具体实现由实现接口的类提供,而在运行时,JVM 根据对象的实际类型来确定要调用的方法实现。
invokespecial
- 描述:
invokespecial
用于调用构造方法、私有方法、以及使用super
关键字调用的父类方法。 - 早期绑定:
invokespecial
通常体现为早期绑定。这些方法调用在编译时就已确定,因为它们不依赖于对象的运行时类型。例如,私有方法不能被重写,构造方法和使用super
调用的父类方法也是明确的。
# 多态与绑定的关系
# 运行时多态与晚期绑定
运行时多态的实现依赖于晚期绑定机制。当你调用一个被重写的方法时,具体调用哪个版本的方法(父类还是子类)是在程序运行时根据对象的实际类型确定的。
# 编译时多态与早期绑定
静态多态,如方法重载,是在编译时就已经决定的。编译器根据方法的签名(如参数类型和数量)来确定要调用的方法。
# 虚方法与非虚方法
# 虚方法(Virtual Methods)
- 定义:虚方法是可以在子类中被覆盖(重写)的方法。在运行时,哪个版本的方法被调用(父类的还是子类的),取决于对象的实际类型。
- 多态:虚方法是实现多态性的关键。一个引用变量可以指向多种实际类型的对象,并且调用同一个方法名可能会执行不同的方法体。
# 非虚方法(Non-Virtual Methods)
- 定义:非虚方法是那些不能在子类中被覆盖的方法。它们与对象的实际类型无关,而是与引用变量的类型相关。
- 限制多态性:由于非虚方法不能被子类覆盖,它们不支持多态性的典型行为。
# 虚拟机中调用方法的指令
# 普通指令
- invokestatic:用于调用静态方法。由于静态方法与类而非类的实例相关联,因此这种调用不依赖于对象的实例。
- invokespecial:用于调用私有方法、实例构造器(
<init>
方法)以及父类方法。这些方法调用在编译时就已经明确,不依赖于方法的多态性。 - invokevirtual:用于调用实例方法。除非方法被声明为 final,否则这种调用支持动态绑定,即方法的调用依赖于对象的实际运行时类型。这是实现多态性(如方法重写)的关键。
- invokeinterface:用于调用接口方法。在运行时,实际调用的方法实现取决于实现了该接口的对象的类型。
# 动态调用指令
- invokedynamic:是 Java 7 引入的一种新的字节码指令,它提供了对动态语言支持的关键。与其他调用指令不同,
invokedynamic
不在编译时绑定方法调用,而是在运行时动态解析。这种指令支持的灵活性使得 JVM 能更好地支持非 Java 语言(如 Ruby 或 JavaScript 在 JVM 上的实现),以及 Java 中的一些高级特性,如 lambda 表达式。
注意
前四条指令固化在虚拟机内部,方法的调用执行不可人为干预。而 invokedynamic 指令则支持由用户确定方法版本。其中 invokestatic 指令和 invokespecial 指令调用的方法称为非虚方法,其余的(final 修饰的除外)称为虚方法。
interface MethodInterface {
void methodA();
}
/**
* 解析调用中非虚方法、虚方法的测试
*
* invokestatic 指令和 invokespecial 指令调用的方法称为非虚方法
*/
class Father {
public Father() {
System.out.println("father 的构造器");
}
public static void showStatic(String str) {
System.out.println("father " + str);
}
public final void showFinal() {
System.out.println("father show final");
}
public void showCommon() {
System.out.println("father 普通方法");
}
}
public class Son extends Father {
public Son() {
//invokespecial
super();
}
public Son(int age) {
//invokespecial
this();
}
//不是重写的父类的静态方法,因为静态方法不能被重写!
public static void showStatic(String str) {
System.out.println("son " + str);
}
public static void main(String[] args) {
Son so = new Son();
so.show();
}
private void showPrivate(String str) {
System.out.println("son private" + str);
}
public void show() {
//invokestatic
showStatic("atguigu.com");
//invokestatic
super.showStatic("good!");
//invokespecial
showPrivate("hello!");
//invokespecial
super.showCommon();
//invokevirtual
showFinal();//即使 showFinal() 被声明为 final,它仍然是一个实例方法,而不是静态或私有方法。实例方法(不包括构造方法、私有方法、静态方法和最终方法)通常是通过 invokevirtual 指令调用的
//如果用了 super.showFinal();,则变为 invokespecial,这样调用就是显示的告诉 jvm 调用的 Father 中的 showFinal()
//虚方法如下:
//invokevirtual
showCommon();
info();
MethodInterface in = null;
//invokeinterface
in.methodA();
}
public void info() {
}
public void display(Father f) {
f.showCommon();
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# 关于 invokedynamic 指令
- JVM 字节码指令集一直比较稳定,一直到 Java7 中才增加了一个 invokedynamic 指令,这是 Java 为了实现【动态类型语言】支持而做的一种改进。
- 但是在 Java7 中并没有提供直接生成 invokedynamic 指令的方法,需要借助 ASM 这种底层字节码工具来产生 invokedynamic 指令。直到 Java8 的 Lambda 表达式的出现,invokedynamic 指令的生成,在 Java 中才有了直接的生成方式。
- Java7 中增加的动态语言类型支持的本质是对 Java 虚拟机规范的修改,而不是对 Java 语言规则的修改,这一块相对来讲比较复杂,增加了虚拟机中的方法调用,最直接的受益者就是运行在 Java 平台的动态语言的编译器。
@FunctionalInterface
interface Func {
public boolean func(String str);
}
public class Lambda {
public void lambda(Func func) {
return;
}
public static void main(String[] args) {
Lambda lambda = new Lambda();
Func func = s -> {
return true;
};
lambda.lambda(func);
lambda.lambda(s -> {
return true;
});
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 动态语言和静态语言
- 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期,满足前者就是静态类型语言,反之是动态类型语言。
- 说的再直白一点就是,静态类型语言是判断变量自身的类型信息;动态类型语言是判断变量值的类型信息,变量没有类型信息,变量值才有类型信息,这是动态语言的一个重要特征。
Java:String info = “mogu blog”; (Java 是静态类型语言的,会先编译就进行类型检查)。
JS:var name = “shkstart”; var name = 10; (运行时才进行检查)。
Python: info = 130.5;(运行时才检查)。
# Java 语言中方法重写的本质
- 找到操作数栈顶的第一个元素所执行的对象的实际类型,记作 C。
- 如果在类型 C 中找到与常量中的描述符合简单名称都相符的方法,则进行访问权限校验。
- 如果通过则返回这个方法的直接引用,查找过程结束。
- 如果不通过,则返回 java.lang.IllegalAccessError 异常。
- 否则,按照继承关系从下往上依次对 C 的各个父类进行第 2 步的搜索和验证过程。
- 如果始终没有找到合适的方法,则抛出 java.lang.AbstractMethodError 异常。
上面这个过程称为动态分派。
IllegalAccessError 介绍
- 程序试图访问或修改一个属性或调用一个方法,这个属性或方法,你没有权限访问。一般的,这个会引起编译器异常。这个错误如果发生在运行时,就说明一个类发生了不兼容的改变。
- 比如,你把应该有的 jar 包放从工程中拿走了,或者 Maven 中存在 jar 包冲突。
# 虚方法表
- 虚方法表的目的:在面向对象语言中,当子类继承父类并重写(覆盖)父类的方法时,虚方法表允许在运行时动态地决定调用哪个方法。这是实现多态的关键。
- 如何工作:
- 当一个类被编译时,编译器为该类及其每个子类生成一个虚方法表。
- 这个表包含了指向类中所有虚拟(动态绑定)方法的指针。对于被子类重写的方法,虚方法表指向子类中的实现。
- 每个对象实例都包含一个指向其类的虚方法表的指针。
- 动态分派:当调用对象的方法时,程序运行时会查看对象的虚方法表,以确定应该执行哪个方法。这样,即使在编译时不知道对象的确切类型,也可以在运行时调用正确的方法。
- 多态性:这种机制允许以统一的方式处理不同类型的对象,而不需要知道它们具体的类别。这增强了代码的灵活性和可重用性。
# 例子
点击查看
- 比如说 Son 在调用 toString 的时候,Son 没有重写过,Son 的父类 Father 也没有重写过,那就直接调用 Object 类的 toString。那么就直接在虚方法表里指明 toString 直接指向 Object 类。
- 下次 Son 对象再调用 toString 就直接去找 Object,不用先找 Son–> 再找 Father–> 最后才到 Object 的这样的一个过程。
# 方法返回地址
注意
一些地方也将方法返回地址、动态链接、一些附加信息叫做帧数据区。
- 存放调用该方法的 PC 寄存器值:程序计数器(PC)寄存器存储着指向下一条要执行的指令的地址。当一个方法被调用时,JVM 会将当前的 PC 寄存器值(即调用该方法的地址)保存起来。这是为了在方法执行完成后能够知道从哪里继续执行。方法的结束有两种情况:正常执行结束和因为未处理的异常而非正常退出。
- 方法退出后的返回:无论方法是正常结束还是异常退出,它都会返回到被调用的位置。对于正常退出的方法,调用者的 PC 计数器的值会作为返回地址,也就是这个方法调用指令的下一条指令的地址。而对于异常退出的情况,返回地址是通过异常表来确定的,在栈帧中通常不会保存这部分信息。
- 方法退出的本质:本质上,方法的退出相当于当前的栈帧从调用栈中出栈。这个过程包括恢复上一个方法的局部变量表、操作数栈等,并将返回值(如果有的话)压入上一个栈帧的操作数栈中。此外,还需要设置 PC 寄存器的值,以便调用者方法可以继续执行。
- 正常出口与异常出口的区别:正常完成的出口和异常完成的出口的主要区别在于,通过异常出口退出的方法不会给它的调用者产生任何返回值。在异常退出时,控制流会被转移到异常处理器,而不是简单地返回到方法调用的下一条指令。
点击查看
正常退出
- 执行引擎遇到任意一个方法返回的字节码指令(return),会有返回值传递给上层的方法调用者,简称正常完成出口。
- 一个方法在正常调用完成之后,究竟需要使用哪一个返回指令,还需要根据方法返回值的实际数据类型而定。
- 在字节码指令中,返回指令包含:
- ireturn:当返回值是 boolean,byte,char,short 和 int 类型时使用。
- lreturn:Long 类型。
- freturn:Float 类型。
- dreturn:Double 类型。
- areturn:引用类型。
- return:返回值类型为 void 的方法、实例初始化方法、类和接口的初始化方法。
异常退出
在方法执行过程中遇到异常(Exception),并且这个异常没有在方法内进行处理,也就是只要在本方法的异常表中没有搜索到匹配的异常处理器,就会导致方法退出,简称异常完成出口。
方法执行过程中,抛出异常时的异常处理,存储在一个异常处理表,方便在发生异常的时候找到处理异常的代码。
- 反编译字节码文件,可得到 Exception table。
- from :字节码指令起始地址。
- to :字节码指令结束地址。
- target :出现异常跳转至地址为 11 的指令执行。
- type :捕获异常的类型。
# 一些附加信息
这包括各种运行时必需的信息,如用于异常处理的信息(如异常表的指针)、安全相关的信息、调试信息等。这些信息帮助 JVM 或类似的环境正确执行程序,处理异常,进行安全检查等。
# 栈的相关面试题
# 举例栈溢出的情况?
栈溢出(Stack Overflow)通常发生在程序递归调用深度过大时。例如,在 Java 中,一个典型的例子是一个递归方法没有正确的退出条件,导致方法不断自我调用,每次调用都会消耗栈空间,最终耗尽栈空间导致栈溢出错误。例如:
public void recursiveMethod(int i) {
recursiveMethod(i + 1);
}
2
3
这个方法因为没有终止条件,会不断递归调用自身,最终导致栈溢出。
# 调整栈大小,就能保证不出现溢出么?
调整栈大小可以在某些情况下减少栈溢出的发生,特别是对于那些栈的使用接近默认栈大小限制的程序。但是,仅仅增加栈大小并不能保证不发生栈溢出。如果程序逻辑存在问题,如无限递归或过深的递归调用,即使栈很大,最终也可能导致溢出。
# 分配的栈内存越大越好么?
不是的。虽然增加栈大小可以让单个线程处理更深的递归调用,但过大的栈内存也有其缺点。首先,它会减少可用于其他线程或其他内存需求(如堆内存)的总内存。其次,过大的栈可能导致系统资源的浪费,特别是在创建大量线程的应用中。因此,栈大小的设置应该根据应用程序的需求和系统资源来平衡。
# 垃圾回收是否涉及到虚拟机栈?
通常情况下,垃圾回收(Garbage Collection, GC)主要处理的是堆内存(Heap Memory),这是因为堆内存用于存放对象实例,而这些对象的生命周期通常较长且不容易预测。虚拟机栈(Java Virtual Machine Stack),另一方面,主要用于存储局部变量和方法调用,其生命周期通常随着方法调用的结束而结束。因此,虚拟机栈中的对象不需要通过垃圾回收来管理。一旦方法调用完成,栈帧就会被移除,与之相关的局部变量也随之销毁。
区域 | 是否有 Error | 是否存在 GC |
---|---|---|
PC 计数器 | 无 | 不存在 |
虚拟机栈 | 有(StackOverflowError, SOF) | 不存在 |
本地方法栈 | 有(可能出现栈溢出或栈内存不足错误) | 不存在 |
堆 | 有(OutOfMemoryError, OOM) | 存在 |
方法区 | 有(可能出现内存溢出错误) | 存在 |
点击查看
- PC 计数器(Program Counter Register)
- 是否有 Error:无。PC 计数器是线程私有的,它记录了当前线程执行的指令地址。由于它仅存储指令地址,因此不会出现 Error。
- 是否存在 GC:不存在。PC 计数器仅存储程序计数信息,不涉及对象存储或管理,因此不会有垃圾回收。
- 虚拟机栈(JVM Stack)
- 是否有 Error:有,栈溢出(StackOverflowError, SOF)。当栈深度超过 JVM 允许的深度时,会抛出栈溢出错误。
- 是否存在 GC:不存在。虚拟机栈主要存储局部变量、操作数栈、方法返回地址等,这些信息随着方法调用的结束而结束,因此不需要垃圾回收。
- 本地方法栈(Native Method Stack)
- 是否有 Error:有,可能出现栈溢出或栈内存不足的错误(在某些 JVM 实现中)。这个栈用于支持本地方法的执行(例如,使用 Java Native Interface 的方法)。
- 是否存在 GC:不存在。与虚拟机栈类似,本地方法栈主要用于方法执行的支持,不涉及对象的长期存储。
- 堆(Heap)
- 是否有 Error:有,内存溢出(OutOfMemoryError, OOM)。当 JVM 无法为新对象分配内存时,因为已经耗尽了全部可用内存,会抛出内存溢出错误。
- 是否存在 GC:存在。堆是存储 Java 对象实例的地方,是垃圾回收的主要区域。
- 方法区(Method Area)
- 是否有 Error:有,可能出现内存溢出错误。方法区用于存储类信息、常量、静态变量等,当空间不足时,可能会出现内存溢出错误。
- 是否存在 GC:存在。虽然方法区的垃圾回收不像堆那么频繁,但类及其相关的对象(如类的静态字段)确实可以被卸载和回收。
# 方法中定义的局部变量是否线程安全?
- 如果只有一个线程才可以操作此数据,则必是线程安全的。
- 如果有多个线程操作此数据,则此数据是共享数据。如果不考虑同步机制的话,会存在线程安全问题。
具体问题具体分析:
- 如果对象是在内部产生,并在内部消亡,没有返回到外部,那么它就是线程安全的,反之则是线程不安全的。
/**
* 面试题:
* 方法中定义的局部变量是否线程安全?具体情况具体分析
*
* 何为线程安全?
* 如果只有一个线程才可以操作此数据,则必是线程安全的。
* 如果有多个线程操作此数据,则此数据是共享数据。如果不考虑同步机制的话,会存在线程安全问题。
*/
public class StringBuilderTest {
int num = 10;
//s1 的声明方式是线程安全的
public static void method1() {
//StringBuilder:线程不安全
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
//...
}
//sBuilder 的操作过程:是线程不安全的
public static void method2(StringBuilder sBuilder) {
sBuilder.append("a");
sBuilder.append("b");
//...
}
//s1 的操作:是线程不安全的
public static StringBuilder method3() {
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
return s1;
}
//s1 的操作:是线程安全的
public static String method4() {
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
return s1.toString();
}
public static void main(String[] args) {
StringBuilder s = new StringBuilder();
new Thread(() -> {
s.append("a");
s.append("b");
}).start();
method2(s);
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54