Java Virtual Machine class

Loading of classes in Java virtual machines

(approximate structure of the JVM)

From sending class files to in-memory classes, in order of precedence, there are three major steps that need to be loaded, linked, and initialized.

The types of Java languages can be divided into two main categories: the base type (primitive type) and the reference type (references type)

Basic type: Is predefined by the Java virtual machine.

Reference type: Java divides it into four types, classes, interfaces, array classes, and generic parameters.

Because generic parameters are erased during compilation (generic types can logically be thought of as multiple different types, they are essentially the same base type.) ), so the Java virtual machine actually has only the first three kinds. In classes, interfaces, and arrays, the array class is generated directly by the Java Virtual machine, and the other two have corresponding byte streams.

BYTE stream: The most common form belongs to a class file generated by the Java compiler. In addition, we can either generate directly within the program or get a byte stream from the network. These different forms of byte stream will be loaded into the Java virtual machine, called classes or interfaces.

Whether it is a directly generated array class or a loaded class, the Java virtual machine is linked and initialized.

Load

Load refers to the process of finding a byte stream and creating a class accordingly. For classes, a Java virtual machine needs to use the ClassLoader to complete the process of finding a byte stream.

When the JVM starts, it forms an initial class loader hierarchy consisting of three classloader:

1. Launch class loader (Bootstrapclassloader): Is embedded in the JVM kernel loader, it is implemented by C + +, there is no corresponding Java object, so in Java can only be replaced with null. It is primarily responsible for loading the class library under Java_home/lib, and the startup ClassLoader cannot be used directly by the application.

In addition to starting the ClassLoader, the other classloader are subclasses of java.lang.ClassLoader and therefore have corresponding Java objects. These classloader need to be loaded by another class loader, such as launching the loader and loading it into a Java virtual machine before it can perform class loading.

Before Java9, the startup ClassLoader was responsible for loading the most basic, most important classes, such as the jar package (and the class specified by the virtual machine parameter-xbootclasspath), stored in the Lib directory of the JRE. In addition to starting the ClassLoader, two other important classloader are the extended class load (Extension class loader) and the application ClassLoader (Application class loader), which are provided by the Java Core Class library.

2, Extension class loader (extension class loader): Its parent class is the startup ClassLoader, he is responsible for loading relatively minor, but common classes, such as stored in the JRE lib/ The class in the jar package in the Ext directory (and the class specified by the system variable Java.ext.dirs).

3. Apply class loader (Application class loader): Its parent class is an extension class loader, which is responsible for loading classes under the Used program. (The application path here is the path defined by the virtual machine parameter-cp/-classpath, the system variable CLASSPATH.) By default, the classes that are contained in the application are loaded by the Application class loader.

JAVA9 introduced the module system, and slightly changed the above class loader, the extension class loader was renamed platform ClassLoader (Platform class loader). In Java SE, in addition to a few key modules, for example, Java.base is loaded by the startup ClassLoader, other modules are loaded by the platform loader.

In addition to the ClassLoader provided by the Java Core Class library, we can also add a custom loader to implement a special loading method. For example, we can encrypt a class file and then load it with a custom class to load the most decryption.

In addition to loading functionality, the ClassLoader also provides the role of namespaces. In a Java virtual machine, the uniqueness of a class is determined by the class loader instance and the full name of the class. Even with a stream of bytes, loaded by different ClassLoader, two different classes are obtained. In large applications, we tend to use this feature to run different versions of the same class.

Link

A link is the process of merging a built-in class into a Java virtual machine to enable it to execute. It can be divided into three stages of verification, preparation and analysis.

Validation: Ensure that the loaded class meets the constraints of the Java Virtual machine, verifies that the loaded class has the correct internal structure, and coordinates with other classes.

Prepare: Allocates memory for the static field of the loaded class and sets the default initial value.

Parse: Replaces the symbolic reference in the binary data in the class with a direct reference (replacement of the final modified constant).

The JVM does not require you to parse during the link process, it only stipulates that if some bytecode uses symbolic references, the parsing of these symbol references needs to be done before these bytecode can be executed.

Initialization

In Java code, if you want to initialize a static field, we can assign a value directly to the declaration, or it can be assigned a value in a static code block.

If the static field of a direct assignment is final decorated, and his type is a primitive type or string, then the field is marked by the Java compiler as a constant value (Constantvalue), and its initialization is done directly by the Java Virtual machine. In addition to the direct assignment operation and the code in all static code blocks, the Java compiler is placed in the same method and named <clinit>.

The final step in class loading is initialization, which is the assignment of a value to a field marked as a constant value, and the process of executing the <clinit> method. The Java virtual Opportunity is locked to ensure that the <clinit> method of the class is executed only once.

A class is formally called an executable state only after initialization is complete.

The JVM Initializes a class into several steps:

1, if this class has not been loaded and linked, the program first load and link to this class.

2. If the immediate parent class of the class has not been initialized, its immediate parent class is initialized first.

3. If there are initialization statements in the class, then execute their initialization statements sequentially.

When the load and initialization of a class is triggered

1. Initializes the user-specified main class when the virtual machine starts. (Use the Java.exe command directly to run a main class)

2. Create an instance of the class (new method).

3. Call the static method of a class and initialize the class where the static method resides.

4. To access the static properties of a class or interface, initialize the class where the static property resides.

5. Use the reflection mechanism to create the corresponding Java.lang.Class object (class.forname ("person") for a class or interface, and initialize the class.

6. Initialization of a subclass triggers the initialization of the parent class.

7, if an interface defines the default method, the initialization of the class that directly implements or indirectly implements the interface will trigger the initialization of that interface.

8. When the Mehodhandle instance is first used, initializes the class that contains the method that the Mehodhandle points to.

Note: This article is for the Geek time Zheng Yudi column, the Java Virtual machine explanation and the study summary of their own data. Zheng Yudi "Deep disassembly of Java virtual machines" is good.

Java Virtual Machine class