The whole process of class loading: loading, verification, preparation, analysis, and initialization.
Loading phase
At this stage, the virtual machine has to complete three things:
- Get the binary byte stream that defines this class through the fully qualified name of a class.
- The static storage structure represented by this byte stream is transformed into the runtime data structure of the method area.
- A java.lang.Class object representing this class is generated in the memory as the access entry for various data of this class in the method area.
The loading phase can be completed by using the built-in class loader in the Java virtual machine, or by a user-defined class loader.
For arrays, the array class is not created by the class loader, it is dynamically constructed directly in memory by the Java virtual machine, but the element type of the array still needs a class loader to complete the loading.
The process of creating an array class follows the following rules:
- If the array type is a reference type, then the recursive loading process will load the component type, and the array will be identified in the class name space of the class loader that loads the component type.
- If the component type of the array is not a reference type (for example, the component type of an int[] array is int), the Java virtual machine will mark the array as connected to the boot class loader.
- The accessibility of the array class is consistent with the accessibility of its components. If the component type is not a reference type, the accessibility of its array class is public by default.
After the loading phase is over, the binary byte stream outside the Java virtual machine is stored in the method area according to the format defined by the virtual machine.
Verification phase
Purpose : To ensure that the information contained in the byte stream of the Class file meets all the constraint requirements of the "Java Virtual Machine Specification", and to ensure that this information will not endanger the security of the virtual machine itself after being run as code.
The verification phase will complete the following four phases of verification actions: file format verification, metadata verification, bytecode verification, and symbol reference verification .
File format verification
Verify that the character stream conforms to the specifications of the Class file format and can be processed by the current virtual machine.
May include the following verification points:
- Whether to start with the magic number 0xCAFFEBABE (Class file header)
- Whether the major and minor version numbers are within the accepted range of the current virtual machine
- Whether there are unsupported constant types in the constants of the constant pool
- . . . . . .
The purpose of this stage: to ensure that the input byte stream can be correctly parsed and stored in the method area, and the format meets the requirements for describing a Java type information. This stage of verification is based on the binary byte stream . After passing, this byte stream will enter the method area of the virtual machine for storage. The next three stages are based on the storage structure of the method area and will not be directly performed. Read and fetch the byte stream.
Metadata verification
In the second stage, semantic analysis is performed on the information described by the bytecode.
Possible verification points:
- Does this class have a parent class (except java.lang.Object, all should have a parent class)
- Whether the parent class of this class inherits a class that is not allowed to be inherited (final modified class)
- If this class is not an abstract class, whether it implements all the methods required by its parent class or interface
- Whether the field method of the class conflicts with the parent class
- . . . . . .
Purpose: To perform semantic verification on class metadata information.
Bytecode verification
The third stage is the most complicated stage in the entire verification process. The purpose is to determine that the program semantics are legal and logical through data flow analysis and control flow analysis. In the second stage, after verifying the data type in the metadata information, the method body of the class (Code attribute in the Class file) is verified and analyzed at this stage to ensure that the verified method will not cause harm during operation Safe behavior of virtual machines.
E.g:
- Ensure that the data type of the operand stack and the instruction code can work together at any time. For example, there will be no such thing as "a data of type int is placed on the operation stack, but the local variable table is loaded according to the long type when used."
- Ensure that any jump connection will not jump to bytecode outside the method body
- Ensure that the type conversion in the method body is always valid
- . . . . . . .
If the bytecode of a method body in a type fails the verification, there must be a problem; it is not necessarily safe to pass the verification.
Symbol reference verification
The verification behavior of the last phase occurs when the virtual machine converts the symbol reference into a direct reference. This conversion action will occur in the third phase of the connection-the parsing phase. It can do the matching check of all kinds of information other than the class itself (various symbol references in the constant pool) to determine whether the class lacks or is forbidden to access certain external classes, methods, fields and other resources it depends on.
Check content:
- Whether the fully qualified name described by the string in the symbol reference can find the corresponding class
- Whether there are methods and fields described by the method field descriptors and simple names in the specified class
Purpose : to ensure the normal execution of the parsing behavior.
The verification phase is important but unnecessary for the virtual machine class loading mechanism. Passed, there will be no impact on the program runtime afterwards.