Detailed resolution of the Java type lifecycle

  • 2020-04-01 02:07:45
  • OfStack

At the start of

Load: reads Java types in binary form into the JVM.
1) generate a binary data stream representing the type by the fully qualified name of the type;
2) parse the binary data stream as the internal data structure in the method area;
3) create an instance of the java.lang.class Class that represents this type;

Connection: merges the read - in type data into the runtime state of the virtual machine.
1) validation: ensure that the Java type data format is correct and suitable for use by the JVM;
2) preparation: allocate memory for this type;
3) resolution: convert the symbol reference in the constant pool into a direct reference;

Initialization: each class and interface is initialized when first used actively. Assign the correct initial value to the class variable;
1) if there is a direct superclass in the class and the direct superclass is not initialized, the direct superclass shall be initialized first;
2) if the class has an initialization method, execute the method;

Only six activities are considered active use:
1) create a new instance of the class
2) call the static method declared in the class
3) abnormal static fields declared in the operation class or interface
4) invoke specific reflection methods in the Java API
5) initialize a subclass of a class
6) specify a class as the initialization class when the JVM starts

Use phase (most of the time)

instantiation

Instantiation approach
There are four ways to explicitly instantiate a class:
1) new operator;
2), call the Class or Java. Lang. Reflect the object Constructor newInstance () method;
3) call the Clone() method of any existing object;
4), through the Java. IO. ObjectInputStream class getObject () method deserialization.

Several ways of implicit instantiation:
1) save the String object of command line parameters;
2) related to Class loading, each type loaded by the JVM implicitly instantiates a Class object to represent this type;
3) related to class loading, when the JVM loads the CONSTANT_String_info entry class that contains the CONSTANT_String_info entry class in the constant pool, new instances of String objects are created to represent these constant strings;
4) generate objects by executing expressions containing string concatenation operators;

Instantiation step
1) allocate memory in the heap to save instance variables of the object;
2) initialize the instance variable to the default initial value;
3) assign the correct initial value to the instance variable by three techniques:
A) if the object is created by clone(), the JVM copies the value from the original instance variable into the new object;
B) if deserialized by the readObject() call of the ObjectInputStream class, the JVM initializes the instance variable by reading the value from the input stream;
C) the instantiation method of the object invoked by the JVM initializes the instance variable of the object to the correct initial value;

Garbage collection and object termination
JVM implementations must have some sort of automatic heap storage management strategy, mostly using the garbage collector. If the class declares a void finalize() method, the garbage collector executes the method before freeing the instance memory.

Any exceptions thrown by the finalize() method that the garbage collector automatically calls are ignored.

End stage

Unmount a type from the JVM
In many cases, the lifecycle of a class in a JVM is similar to that of an object. How the JVM determines whether a dynamically loaded type is still being used by a program is very similar to how it determines whether an object is still being used.

If the program no longer references a type, the type is untouchable and can be unloaded.

The type loaded with the boot class loader is always reachable, so it can never be unloaded. Only a type loaded with a user-defined classloader becomes untouchable and unloaded.


Related articles: