Java Virtual machine Learning (1): Class loading mechanism

Turn from: Public number importnew

Source: JAVA2000_WL

Links: blog.csdn.net/java2000_wl/article/details/8040633

The process of the JVM loading the class file into memory, validating the data, parsing and initializing it, and finally forming the Java type that the JVM can use directly is the loading mechanism.

Class starts from being loaded into the virtual machine's memory, and its lifecycle includes: Load (Loading), validate (verification), prepare (preparation), Parse (Resolution), Initialize ( initialization), use (using), unload (unloading) Seven stages, where validation, preparation, parsing three parts are collectively referred to as links.

Load (mount), validate, prepare, initialize, and unload the five stage sequence is fixed, and the class's loading process must begin in this order, while the parsing phase is not necessarily; it can be started after initialization in some cases, for runtime dynamic binding attributes. It is important to note that these phases are usually mixed with each other, usually invoking or activating another phase during one phase of execution.

Load:

The load phase is a phase in the class loading mechanism, which is often referred to as "loading," and is mainly done by:

1. Obtain a binary byte stream that defines this class by "full name of Class"

2. Convert the static storage structure represented by the byte stream to the run-time data structure of the method area

3. Generate a Java.lang.Class object representing this class in the Java heap as the access entry for the data in the method area

The virtual machine specification for the "Pass" class full name "To obtain a binary byte stream defined by this class" does not indicate that the binary stream must be fetched from a local class file, but not exactly where it is to be obtained and how it is obtained. For example:

• Read from the ZIP package, which is common and eventually becomes the basis for future jar, EAR, and war formats.

• Get from the network, common application applets.

• Run-time compute generation, this scenario uses most of the dynamic agent technology, in Java.lang.reflect.Proxy, is to use Proxygenerator.generateproxyclass for a specific interface to generate $ The binary byte stream of the Prxoy proxy class.

• Generated by other format files, typical scenario: JSP application

• This scenario is relatively rare when read from a database, and some middleware servers (such as SAP Netweaver) can choose to install the program into a database to complete the distribution of program code between clusters.

In contrast to other stages of the class loading process, the load phase (prepared to take the action of getting the binary byte stream of the class during the load phase) is the most controllable phase of the development period, because the load phase can be done using the system-provided ClassLoader (ClassLoader), or it can be done by a user-defined ClassLoader. Developers can control the way a byte stream is obtained by defining its own classloader.

After the loading phase is complete, the binary byte stream outside the virtual machine is stored in the method area according to the format required by the virtual machine, the data storage format in the method area is defined by the virtual machine, and the virtual machine does not specify the specific data structure of this area. An object of the Java.lang.Class class is then instantiated in the Java heap, which acts as an external interface for the program to access these types of data in the method area. The load phase and part of the link phase (such as some bytecode file format validation actions) are cross-over, the loading phase is not complete, the link stage may have started, but the actions taken during the loading phase of these clips are still part of the link stage, and the start time of the two phases remains in a fixed order.

Verify:

Validation is the first step in the link phase, and the primary purpose of this step is to ensure that the information contained in the byte stream of the class file conforms to the requirements of the current virtual machine and does not compromise the virtual machine itself.

The verification phase consists of four inspection processes: file format validation, metadata validation, bytecode validation, and symbolic reference validation.

1. File Format Verification

Verify the class file format specification, such as whether the class file has started with Magic 0xCAFEBABE, whether the main or minor version number is within the current virtual machine processing range, etc.

2. Meta-data validation

This phase is a semantic analysis of the information described in bytecode to ensure that the information described is in accordance with the Java language specification. Validation points may include whether the class has a parent class (except for Java.lang.Object, all classes should have a parent class), whether the class inherits from a class that is not allowed to inherit (final decorated), and if the parent class of the class is an abstract class. Whether all the methods required to implement in the parent class or interface are implemented.

3. Byte code Verification

For data flow and control flow analysis, this phase verifies the method body of a class, and the task of this phase is to ensure that the method of the checked class does not act to compromise the security of the virtual machine at runtime. such as: To ensure that the type conversion in the body of the visit is valid, for example, a subclass object can be assigned to the parent data type, which is safe, but not a parent class object to the subclass data type, ensure that the jump command does not jump to the bytecode command outside the method body.

4. Symbol Reference Validation

The fully qualified name that is described by a string in a symbol reference can find the corresponding class, the class in the symbol reference class, and whether the accessibility of the field and method (private, protected, public, default) can be accessed by the current class.

Get ready:

The prep phase is a phase that formally allocates memory for class variables and sets the initial value of class variables, which are allocated in the method area. There are two confusing points of knowledge at this stage, first of all the memory allocations are only the class variables (static modified variables), not the instance variables, and the instance variables will be allocated in the Java heap along with the object when the object is instantiated. The second is that the initial value described here is the 0 value of the data type under "normal circumstances", assuming that a class variable is defined as:

public static int value = 12;

Then the initial value of the variable value after the prep phase is 0 instead of 12, since no Java method has started executing, and the putstatic instruction that assigns value 123 is that the program is compiled and stored in the class constructor <clinit> () method, So an action that assigns value to 12 will not be executed until the initialization stage.

The initial value under "Normal" above is 0, which is relative to some special cases, if the Constantvalue attribute exists in the field attribute table of the class field, then in the prepare phase the variable value is initialized to the value specified by the Constantvalue property. Building the above class variable value is defined as:

public static final int value = 123;

Compile-time Javac will generate the Constantvalue property for value, and in the prepare phase the virtual machine will set value to 123 based on the settings of Constantvalue.

Analytical:

The parsing phase is the process of replacing a symbolic reference in a virtual machine constant pool with a direct reference.

Symbol Reference: A symbol reference is a set of symbols that describe the target object being referenced, and the symbol can be any form of literal, as long as it can be used without ambiguity to locate the target. The symbolic reference is independent of the memory layout implemented by the virtual machine, and the referenced target object is not necessarily loaded into memory.

Direct reference: A direct reference can be a pointer to a target object directly, a relative offset, or a handle that can be indirectly anchored to the target. Direct references are related to virtual machine memory layout implementations, and direct references that are translated on different virtual machine instances by the same symbol reference are generally not the same, and if there is a direct reference, the referenced target must already exist in memory.

The virtual machine specification does not specify the time for the parsing phase to occur, only the execution of Anewarry, Checkcast, GetField, instanceof, Invokeinterface, Invokespecial, invokestatic , Invokevirtual, Multianewarray, New, Putfield, and putstatic the 13 byte-code directives used to manipulate symbol references are parsed before they are used by the symbol reference, so the virtual machine implementation is judged as needed. Whether to parse a symbolic reference in a constant pool when the class loader is loaded, or to parse a symbol reference before it is to be used.

The parsed actions are mainly for class or interface, field, class method, interface method and four kinds of symbolic references. corresponding to Constant_class_info, Constant_fieldref_info, Constant_methodef_info, constant_interfacemethoder_ in the compiled constant pool, respectively Info four types of constants.

1. Parsing of classes and interfaces

2. Field resolution

3. Class method parsing

4. Interface Method Parsing

Initialization

The initialization phase of a class is the last step in the class loading process, where class variables have been assigned the initial value of a system requirement at the time of initialization, and in the initial phase, class variables and other resources are initialized based on a subjective plan devised by the programmer, or can be expressed from another angle: The initialization phase is the execution class constructor The <clinit> () method process. The initialization process is triggered in the following four scenarios:

1. When encountering the 4 bytecode directives of new, getstatic, putstatic, or invokestatic, if the class has not been initialized, it is necessary to trigger its initialization first. The most common Java code scenario for generating these 4 instructions is when you instantiate an object with the New keyword, read or set a static field of a class (except for the static fields that were final decorated, have been placed in a constant pool by the compiler), and when you invoke a static method of the class.

2. When a reflection call is made to a class using the Java.lang.reflect package method

3. When initializing a class, if it is found that its parent has not yet been initialized, it is necessary to start the initialization of its parent class.

At 4.JVM startup, the user specifies a main class of execution (the class that contains the main method), and the virtual opportunity initializes the class first.

In the preparation stage above public static int value = 12; After the preparation phase is complete, value is 0, and the class constructor <clinit> () method is called in the initialization order, and the value of the period is 12.

The class constructor <clinit> () method is generated by the combination of the assignment of all class variables in the compiler's automatic collection of classes and the statements in the static statement block (static block), and the order in which the compiler collects is determined by the order in which the statements appear in the source file. A static statement block can only access variables that are defined before a static statement block, the variables that are defined after it, and the static statements in front are fast to be assigned, but cannot be accessed.

The class constructor <clinit> () method differs from the class's constructor (instance constructor <init> () method), which does not require explicit invocation of the parent class construct, and the virtual opportunity guarantees that the parent class's < before the subclass <clinit> () method executes The Clinit> () method has been executed. So the first execution of the <clinit> () method in the virtual machine class is definitely java.lang.Object.

* Because the <clinit> () method of the parent class executes first, it means that the static statement defined in the parent class is going to take precedence over the variable assignment operation of the child class.

The *<clinit> () method is not necessary for a class or interface, and the compiler can not generate a <clinit> () method for this class if there is no static statement in a class and there is no operation to assign a variable.

* Static statement blocks cannot be used in interfaces, but interfaces and classes are not very capable of executing an interface's <clinit> () method without first executing the parent interface's <clinit> () method. The parent interface is initialized only if the variable defined in the parent interface is used. In addition, the implementation class of the interface does not execute the <clinit> () method of the interface at initialization time.

* Virtual opportunity to ensure that a class <clinit> () method is properly locked and synchronized in a multithreaded environment, if multiple threads are initializing a class at the same time, then only one thread will execute the class's <clinit> () method, and other threads will need to block the wait. Until the active thread executes the <clinit> () method is complete. If a class's <clinit> () method has long-time operations, it can cause multiple processes to block.

Java Virtual machine Learning (1): Class loading mechanism