Java class loading study notes

Class loading process

1. Load : Read the bytecode file of the class from the hard disk to the JVM method area, and create the Class object in the heap at the same time
2. Verification : verify the correctness of the bytecode file
3. Preparation : Allocate memory for the static variables of the class and initialize the default value (the default value of int is 0, the initialized value here is not determined by the code, even if the code is static int a = 3, the initialization is also 0)
4. Analysis : Convert the symbol reference in the class (the code name when the other party does not allocate memory) to a direct reference (the memory area where the object is located)
5. Initialization : initialize the static variables of the class to the specified value (this is the initial value assigned to the code ), and execute the static code block

The above operations are all done by the  class loader   .

 

Low-level detailed process of class loading

(The first three steps are all implemented by C++)

1. Call java com.codersan.xxxx to execute java program
2. The java.exe under the window system calls the underlying jvm.dll file (C++) to create a Java virtual machine
3. Create a boot class loader instances (also in C ++)
4. C++ calls Java code to create a JVM launcher instance (sun.misc.Launcher) . This class is loaded by the boot class loader, and other class loaders are created at the same time.
5. Get the ClassLoader of the running class's own loader, the default is an instance of AppClassLoader
6. Call the loadCLass method to load the class XXXX that needs to be run    classLoader.loadClass("com.codersan.xxxx")
7. When loading is complete, JVM executes the main method entry
8. The java Cheng Xun run ends and the JVM is destroyed

 

Three types of loaders

Parental delegation mechanism: from top to bottom, the parent-child relationship (non-inheritance relationship, the latter two are the first static internal classes), the child loader will load it when the parent loader fails to load

Reasons: 1. Avoid repeated loading of classes 2. Sandbox security mechanism (String.class written by yourself will not be loaded to prevent the core API library from being tampered with at will)

• Bootstrap ClassLoader: Load the core class libraries in the jre/lib directory, such as rt.jar (including String, lang, etc.) , charsets.jar
• Extension ClassLoader: Load the Jar class package in the jre/lib/ext directory
• Application ClassLoader (Application ClassLoader): load the class bytecode file under the ClassPath path class path, load the class written by yourself

 

 

Assuming that there are A.class in the three jar reports of ext*.jar and rt.jar under the classpath, how many times will A.class be loaded? What is the loading sequence?

 

Will not be loaded 3 times, there will be the top boot class loader to load

 

Custom class loader

Inherit the java.lang.ClassLoader class and override the findClass method. The parent loader will be set as the application class loader.

Break the parent delegation mechanism by rewriting the loadClass method.

 

 

Tomcat breaks the parent delegation mechanism

For example, the war package under the Tomcat container may involve different Springs, such as Spring 4 and Spring 5. The package names involved may be the same, but the implementation is different. At this time, the parent delegation mechanism needs to be broken.