[JVM series (1)] class loading mechanism

class loading mechanism

1, the class loading process

ClassLoader is only responsible for the loading of class files, and whether it can be run or not is determined by the Execution Engine.

Loading phase:

1. Get the binary byte stream of a class by its full class name;
2. Convert the static storage structure represented by the stream to the runtime data structure of the method area;
3. Generate a java.lang.Class object representing this class in memory as the access entry of this class in the method area.

Link stage:

• Verify (Verify) :

  Ensure that the information contained in the byte stream of the Class file meets the requirements of the current virtual machine to ensure the correctness of the loaded class;

  It mainly includes four kinds of verification, file format verification, metadata verification, bytecode verification, and symbol reference verification.

• Prepare (Prepare) :

  The main job is to allocate memory for class variables (to the method area) and set the default initial value of the class variable, which is zero.

  The allocated memory here does not include class variables decorated with final, because they will be allocated at compile time, and will be explicitly initialized in the preparation phase;

  There is no allocation initialization for instance variables here, instance variables are allocated to the Java heap along with the object.

• Resolve :

  The main job is the process of converting symbolic references in the constant pool to direct references.

  A symbolic reference is a set of symbols to describe the referenced object. A direct reference is a pointer directly to the target, a relative offset, or a handle that is located indirectly to the target.

  Parsing actions are mainly for classes or interfaces, fields, class methods, interface methods, method types, etc. Corresponds to CONSTANT_Class_info, CONSTANT_Fieldref_info, CONSTANT_Methodref_info, etc. in the constant pool.

  Reference link:

  https://www.yuque.com/u21195183/jvm/rq9lt4

2. Class loader classification

Class loaders are generally divided into Bootstrap ClassLoader and User-Defined ClassLoader.

The custom class loader here actually includes the extension class loader (Extension ClassLoader) and the system class loader, AppClassLoader), which is only different from the Bootstrap ClassLoader implemented by c/c++ inside the JVM.

Of course, users can write their own loaders according to their needs. The basic needs can be realized by inheriting the URLClassLoader class. The corresponding methods include loacClass, findClass, findLoadClass, etc.

https://www.cnblogs.com/leiqiannian/p/7922824.html

3. Parent delegation mechanism in class loading

The loading mechanism of classes is loaded by delegation layer by layer, that is, according to the delegation form of AppClassLoader->Extension ClassLoader->Bootstrap ClassLoader, only when the root class Bootstrap ClassLoader cannot be loaded, it will try to load it by itself, otherwise ClassNotFindException will be thrown. A class referenced in another class will also follow the loader mechanism of that class.

The advantages of this mechanism are obvious:

• To avoid repeated loading of classes, the upper-level loader loads first, and subclasses do not need to be loaded again after loading.
• Sandbox security mechanism, the core API must follow the implementation class of the system to prevent malicious tampering.

Corresponding to the parent delegation mechanism is the overall delegation mechanism, that is, a class is responsible for a ClassLoader from beginning to end, unless other ClassLoaders are explicitly used.

Have you ever wondered if this way will lead to closure? Parental delegation is actually a one-way loading mechanism. How to solve the problem when the loading of the parent class depends on the loading of the child class? For example, the Service Provider Interface (SPI) provided by Java includes the loading implementation of JDBC, JNDI, etc.

/**
 * 向 DriverManager 注册指定的驱动程序
 */
DriverManager.registerDriver(java.sql.Driver driver)

The DriverManager will be loaded by the system class loader first, and then find the bootstrap class loader to complete the loading, and the driver class it depends on is implemented by the JDBC manufacturer. Obviously, the bootstrap class loader cannot complete the loading. To this end, this problem can be solved by delegating to the thread context loader ContextClassLoader. That is to say, ContextClassLoader breaks the one-way addition of parental delegation and solves the loading problem of third-party class libraries.

Reference link:

https://www.cnblogs.com/doit8791/p/5820037.html

https://www.cnblogs.com/lxchinesszz/p/12130531.html

4. The loading order of classes

When a class is not loaded, it executes in the following loading order:

1. First load the execution class;
2. Load static variables and static code blocks in sequence;
3. Load the main method;
4. When the new current class object method will trigger the loading of other unloaded things in the class, other variables and anonymous code blocks will be loaded in sequence here, and finally the default constructor will be loaded;

Of course, the class with inheritance relationship will firstly load the static variables and instance variables of the parent class according to the above method.

For classes that have been loaded, static code blocks and static variables do not need to be executed repeatedly, and only relevant instance variables and constructors need to be executed when an object is created.

Reference link:

https://www.cnblogs.com/leiqiannian/p/7922824.html