1. Class files

A class file is a binary byte stream based on 8-bit bytes.

Figure 1-1. Class file bytecode diagram

2. Class lifecycle

Load - Verify - Prepare - Parse - initialize - Use - unload

In some cases, parsing can be done after initialization to support dynamic binding.

Figure 2-1. Class lifecycle diagram

3. The class loading

Loading stage – Verification stage – Preparation stage – Parsing stage – Initialization stage Loading stage mainly uses the class loader, according to the fully qualified name of the class, to obtain the binary byte stream of the class; In the verification stage, text format, metadata, bytecode and symbol reference are verified. The preparation phase allocates memory for static variables in the non-heap and sets the initial value to zero. In the parsing phase, symbolic references in the constant pool are replaced with direct references. The initialization phase begins bytecode execution, initializing class variables and other resources, assigning values to static variables, and so on.

3.1 loading

Loading is only the first stage of class loading. The whole process of class loading includes loading, verification, preparation, parsing, and initialization.

  • design

The binary byte stream that defines this Class is obtained by the fully qualified name of the Class, and the static storage structure represented by the byte stream is converted into a runtime data structure, generating java.lang.class objects in memory.

Binary byte streams can be obtained by class fully qualified names by (1) reading from jar, WAR, WAR, ZIP packages (2) reading from the network (3) dynamic proxies (4) generating from other files (5) reading from the database

3.2 validation

Validation is an important but not necessary part of the class loading phase. You can shorten the class loading time by disabling -xVerify: None.

  • design

Verify that the byte stream of the class file meets the requirements of the current JVM to ensure that it is safe for the current JVM.

  • implementation

Text format verification, metadata verification, bytecode verification, symbol reference verification.

(1) file format verification Verifies whether the byte stream complies with the class file format specification to ensure that it can be processed by the current JVM. (2) Metadata verification verifies the semantics of the metadata information of the class to ensure that it complies with the Java language specification. (3) Bytecode verification verifies the method body of the class. Verify the bytecode of the class method body to ensure that the program semantics are legal and logical; (4) Symbolic reference validation ensures that the parsing action can be performed normally

Type check: Add StackMapTable property to the property table of the method body Code property, which describes the state of the local variation table and operation stack when all the basic blocks in the method body start. During bytecode verification, check whether the records in the StackMapTable property are valid.

Data flow validation is complex. JDK6 and JDK7 implement type checking. After JDK7, for class files with major version numbers greater than 50, type checking is used to complete data flow verification.

3.3 to prepare

  • design

Prep is to allocate memory for static variables of a class in the non-heap and set their initial values.

  • Examples and Instructions
public static int valuie = 1;
Copy the code

In general, during the preparation phase, static variables allocate memory in the non-heap, and the initial value of static variables in the preparation phase is zero. The initialization phase assigns 123 to value.

public static final int valuie = 1;
Copy the code

In the special case of a final modified static variable, the ConstantValue attribute is generated for value at compile time, and value is assigned a value of 1 based on ConstantValue during preparation.

(Boolean)false, (byte)0, (char)’\u0000′, (short)0, (int)0, (float)0.0f, (long)0, (double)0.0d; The value of reference type zero is (reference) NULL.

3.4 analytical

The parsing phase is the process by which the JVM replaces symbolic references in the constant pool with direct references.

  • design

The parse action is mainly for the following seven types of symbolic references. The mapping between symbolic references and constant types is shown in the following table.

Symbolic reference Constant type
Class or interface CONSTANT_Class_info
field CONSTANT_Fieldref_info
Class method CONSTANT_Methodref_info
Interface methods CONSTANT_InterfaceMethodref_info
Method type CONSTANT_MethodType_info
Method handles CONSTANT_MethodHandle_info
Call the point qualifier CONSTANT_InvokeDynamic_info

(1) Symbolic reference describes the referenced object as a set of symbols, which can be any form of literal. (2) Directly reference the pointer directly to the target, relative offset, or indirectly located to the target handle.

3.5 the initialization

The first four stages of load, validation, preparation, and parsing are all dominated by the JVM; The initialization phase begins the execution of the bytecode program.

  • design

Initialize class variables or other resources based on Java program code

Class initialization scenario

(1) When the four bytecode instructions of New, getstatic, putstatic and Invokestatic are encountered, their initialization needs to be triggered first; (2) Java.lang.Reflect will trigger initialization if the class has not been initialized; (3) When a class is initialized, if the parent class is not initialized, the parent class needs to trigger initialization. (4) When the JVM starts, it needs to specify a primary class, which needs to be initialized first. (5) Java. Lang. Invoke. The resolved results is REF_getStatic MethodHandle instance, REF_putStatic, REF_invokeStatic method handles, method handles the corresponding class has not been initialized, the initialization corresponds to the first class

Class loaders

The loading phase of class loading is to get the binary byte stream describing the class based on its fully qualified name. The code module that implements the loading action is the class loader. The class loader and the class itself ensure that it is unique within the JVM. The same class file is processed by different class loaders and the resulting classes are not equal.

4.1 JVM perspective Distinguishes between two types of loaders

  • Start the class loader

The Bootstrap ClassLoader is part of the JVM and is implemented in C++.

  • Non-startup class loaders

Other classloaders inherit from java.lang.ClassLoader and are implemented by Java, independent of the JVM.

4.2 Three types of loaders provided by the system in Java programs

The application class loader is also called the system class loader to prevent confusion. Other parts of the article refer to this loader and collectively referred to as the system class loader. In general, the system class loader is used by default when there is no custom class loader in the program. Custom class loaders are non-boot class loaders that are customized by application developers.

  • Start the Bootstrap ClassLoader
  • Extension ClassLoader Extension ClassLoader
  • The Application ClassLoader
category Programs can be referenced directly Class libraries that support loading
Start the class loader no Class libraries in the JAVA_HOME\lib directoryandThe -xbootCLASspath argument specifies the class library in the path
Extend the class loader is Class libraries in the JAVA_HOME lib ext directoryandThe system variable java.ext.dirs specifies the class libraries in the path
System class loader is The system variable classpath specifies the class libraries in the path
Custom class loaders is
### 4.3 Parent delegate model for class loaders
FIG. 4-1 Model diagram of parental delegation
  • Parental delegation model

The hierarchical relationship of class loaders depicted in figure 4-1’s parent delegate model is called the parent delegate model of class loaders.

  • The working principle of

A classloader receives a classloading request and delegates the request to the parent classloader. If the parent classloader fails to find the required class and cannot complete the load, the child classloader attempts to load the class.

The existence of precedence between class loaders gives precedence to classes, ensuring that the class being loaded is the same class in all class loaders. Instead of saying that class loaders and classes themselves are guaranteed to be unique within the JVM, classes are guaranteed to be loaded by the top class loaders through delegation. The parent delegate model is the official recommended implementation of class loaders. It is not mandatory, and in some cases is not the parent delegate model. For example, threads provide context class loaders that you can specify to use in your program.

5. Class file structure (extended reading)

The class file structure contains magic and file versions, constant pools, access flags, class indexes, parent class indexes and interface index collections, field table collections, method table collections, and property table collections. Class file format supports two data types: unsigned number and table. The essence of class file is table.

There are two types of data in the pseudo-structure of class files: unsigned numbers are basic data types, and tables are compound data types composed of multiple unsigned numbers or other tables. Unsigned number, u1, U2, u4, u8 represent unsigned numbers of 1, 2, 4, and 8 bytes respectively. Can be used to describe numbers, index references, quantitative values, or string values.

5.1 Magic numbers and file versions

A class file is a binary stream based on 8 bytes. Open a class file with Notepad, and part of the byte information is shown below.

cafe babe 0000 0034 0013 0a00 0400 0f0a
0004 0010 0700 1107 0012 0100 063c 696e
6974 3e01 0003 2829 5601 0004 436f 6465.Copy the code

The magic number

  • define

The first four bytes of the class file are the magic number, with a fixed hex value of 0xcafeBabe

File version

  • define

The 5-8 bytes of a class file identify the class file version. The hexadecimal value of the minor version number is 0x0000, and the hexadecimal value of the major version number is 0x0034. The decimal version number is 52.0.

5.2 constant pool

The constant pool holds literals and symbol reference literals

  • define

This can be understood as a Java constant

Symbolic reference

  • role

Include the following three types of constants: (1) fully qualified names of classes and interfaces; (2) The name and descriptor of the field; (3) Method name and descriptor

5.3 Access Flags

  • define

After the constant pool ends, the next two bytes describe the access flag;

  • role

Access information used to identify a class or interface, such as whether the class, interface, is abstract, public, or final

5.4 Set of Class Indexes, parent Indexes, and interface Indexes

  • define

A class index and a parent index are u2-type data, and an interface index is a collection of U2-type data.

  • role

The class index describes the current class, the superclass index describes which class inherits, and the interface index collection describes which interfaces implement. These three data are used to determine the inheritance relationship of the current class.

Java single inheritance, a maximum of one parent class, java.lang.Object has no parent class. Basic data types are sufficient for class and parent indexes; The index of the parent class of java.lang.Object is 0. Java multi-implementation, support implementation of multiple interfaces, so use collections

5.5 Field table Set, method table set, and Property table set

Set of field tables

  • define

Describes variables declared in an interface or class. Fields include class-level and instance-level variables, not method-local variables

  • structure

Access flags, name indexes, descriptor indexes, and property list collections

Access_flags Field modifiers are placed in access flags, such as public, static, final, volatile, transient name (name_index) Generic simple names (for example: Method names notify, equals, field names obj), fully qualified names (e.g. Java /lang/Object) Descriptor_index Describes the data type of the field, the parameter list of the method, and the collection of returned value property tables to store additional information, describing zero or more additional information.

Method table collection

  • define

In the class file storage format, the description of methods is almost identical to the description of fields. The method table structure is the same as the field table structure, including the access flag, the name index, the descriptor index, the property table set.

Property sheet collection

  • define

Class files, field tables, and method tables can all carry their own set of attributes to describe information specific to certain scenarios

Method tables differ from field tables in access flags. Volatile and TRANSIENT do not modify methods, so the access flags of the method table do not include ACC_VOLATILE and ACC_TRANSIENT flags. Methods can be modified by synchronized, native, STRICtFP and abstract, and ACC_SYNCHRONIZED, ACC_NATIVE, ACC_STRICTFP and ACC_ABSTRACT are added to the method table flags.

Powered By niaonao