JVM 学习（一）

最新推荐文章于 2024-11-28 11:17:05 发布

Romon_G

最新推荐文章于 2024-11-28 11:17:05 发布

阅读量93

点赞数

分类专栏：记录文章标签： jvm java

本文链接：https://blog.youkuaiyun.com/weixin_46475802/article/details/119852099

版权

记录专栏收录该内容

12 篇文章

订阅专栏

本文详细介绍了JVM的工作原理，包括从源码到字节码的编译过程，类加载机制的双亲委派模型，以及运行时数据区的结构如方法区、堆、虚拟机栈和本地方法栈。同时，讨论了类加载的验证、准备、解析和初始化阶段，以及程序计数器的作用。内容涵盖了JVM的关键概念，有助于深入理解Java内存管理和执行机制。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

JVM 学习（一）

JDK8官网地址
https://docs.oracle.com/javase/8/

1、源码文件到类文件（.java --> .class）

1.1、编译过程

Test.java - 词法分析器 – token流 – 语法分析器 – 语法树 – 语义分析器 – 注解抽象语法树 – 字节码生成器 – Test.class

1.2、类文件内容（class文件内容）

The ClassFile Structure:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html

ClassFile {
    u4             magic;
    u2             minor_version;
    u2             major_version;
    u2             constant_pool_count;
    cp_info        constant_pool[constant_pool_count-1];
    u2             access_flags;
    u2             this_class;
    u2             super_class;
    u2             interfaces_count;
    u2             interfaces[interfaces_count];
    u2             fields_count;
    field_info     fields[fields_count];
    u2             methods_count;
    method_info    methods[methods_count];
    u2             attributes_count;
    attribute_info attributes[attributes_count];
}

2、类加载机制

2.1、类加载机制图解：

在这里插入图片描述

加载（装载）：
查找和导入class文件
链接
2.1 验证

保证加载类的正确性：
1、文件格式验证；
2、元数据验证；
3、字节码验证；

2.2 准备:

为类的静态变量分配内存，并将其初始化为默认值

2.3 解析：

把类中的符号引用转换为直接引用
初始化:

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

2.2 双亲委派机制：

定义：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把
这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就
成功返回；只有父类加载器无法完成此加载任务时，才自己去加载
优势：Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如，Java中的
Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型
最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用
双亲委派模型，那么由各个类加载器自己取加载的话，那么系统中会存在多种不同的Object
类。
破坏：可以继承ClassLoader类，然后重写其中的loadClass方法，其他方式大家可以自己了解
拓展一下。

3、运行时数据区：

在这里插入图片描述

3.1、方法区 MethodArea：

方法区是各个线程共享的内存区域，在虚拟机启动时创建。
用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

2.5.4. Method Area
The Java Virtual Machine has a method area that is shared among all Java Virtual Machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in an operating system process. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors, including the special methods (§2.9) used in class and instance initialization and interface initialization.

The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.

The following exceptional condition is associated with the method area:

If memory in the method area cannot be made available to satisfy an allocation request, the Java Virtual Machine throws an OutOfMemoryError.

虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却又一个别名叫做Non-Heap(非堆)，目
的是与Java堆区分开来。
当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

3.2、堆 Heap

Java堆是Java虚拟机所管理内存中最大的一块，在虚拟机启动时创建，被所有线程共享。
Java对象实例以及数组都在堆上分配。

2.5.3. Heap
The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.

The following exceptional condition is associated with the heap:

If a computation requires more heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an OutOfMemoryError.

3.3 栈 stack

3.2.1 虚拟机栈 Java Virtual Machine Stacks

虚拟机栈是一个线程执行的区域，保存着一个线程中方法的调用状态。换句话说，一个Java线程的运行
状态，由一个虚拟机栈来保存，所以虚拟机栈肯定是线程私有的，独有的，随着线程的创建而创建。
每一个被线程执行的方法，为该栈中的栈帧，即每个方法对应一个栈帧。
调用一个方法，就会向栈中压入一个栈帧；一个方法调用完成，就会把该栈帧从栈中弹出。

2.5.2. Java Virtual Machine Stacks
Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6). A Java Virtual Machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java Virtual Machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java Virtual Machine stack does not need to be contiguous.

In the First Edition of The Java® Virtual Machine Specification, the Java Virtual Machine stack was known as the Java stack.

This specification permits Java Virtual Machine stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the Java Virtual Machine stacks are of a fixed size, the size of each Java Virtual Machine stack may be chosen independently when that stack is created.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of Java Virtual Machine stacks, as well as, in the case of dynamically expanding or contracting Java Virtual Machine stacks, control over the maximum and minimum sizes.

The following exceptional conditions are associated with Java Virtual Machine stacks:

If the computation in a thread requires a larger Java Virtual Machine stack than is permitted, the Java Virtual Machine throws a StackOverflowError.

If Java Virtual Machine stacks can be dynamically expanded, and expansion is attempted but insufficient memory can be made available to effect the expansion, or if insufficient memory can be made available to create the initial Java Virtual Machine stack for a new thread, the Java Virtual Machine throws an OutOfMemoryError.

3.2.2 本地方法栈 Native Method Stacks

如果当前线程执行的方法是Native类型的，这些方法就会在本地方法栈中执行。

2.5.6. Native Method Stacks
An implementation of the Java Virtual Machine may use conventional stacks, colloquially called "C stacks," to support native methods (methods written in a language other than the Java programming language). Native method stacks may also be used by the implementation of an interpreter for the Java Virtual Machine's instruction set in a language such as C. Java Virtual Machine implementations that cannot load native methods and that do not themselves rely on conventional stacks need not supply native method stacks. If supplied, native method stacks are typically allocated per thread when each thread is created.

This specification permits native method stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the native method stacks are of a fixed size, the size of each native method stack may be chosen independently when that stack is created.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the native method stacks, as well as, in the case of varying-size native method stacks, control over the maximum and minimum method stack sizes.

The following exceptional conditions are associated with native method stacks:

If the computation in a thread requires a larger native method stack than is permitted, the Java Virtual Machine throws a StackOverflowError.

If native method stacks can be dynamically expanded and native method stack expansion is attempted but insufficient memory can be made available, or if insufficient memory can be made available to create the initial native method stack for a new thread, the Java Virtual Machine throws an OutOfMemoryError.

3.4 程序计数器：

程序计数器占用的内存空间很小，由于Java虚拟机的多线程是通过线程轮流切换，并分配处理器执行时
间的方式来实现的，在任意时刻，一个处理器只会执行一条线程中的指令。因此，为了线程切换后能够
恢复到正确的执行位置，每条线程需要有一个独立的程序计数器(线程私有)。
如果线程正在执行Java方法，则计数器记录的是正在执行的虚拟机字节码指令的地址；
如果正在执行的是Native方法，则这个计数器为空。

2.5.1. The pc Register
The Java Virtual Machine can support many threads of execution at once (JLS §17). Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method (§2.6) for that thread. If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed. If the method currently being executed by the thread is native, the value of the Java Virtual Machine's pc register is undefined. The Java Virtual Machine's pc register is wide enough to hold a returnAddress or a native pointer on the specific platform.