JVM class loading mechanism

One 、 Class loading steps

 JVM Lazy loading mechanism is adopted , That is, only classes are loaded when they are used . Class loading can be divided into the following steps ：

load ： That is, load the class bytecode file into memory , In the next step, a class representing this class will be generated in memory java.lang.Class object , As the access to all kinds of data of this class in method area .

verification ： Verify the accuracy of bytecode files , Each bytecode file has a fixed format , To verify whether the bytecode file is damaged .

Get ready ： Allocate memory space to static variables and assign default values .

analysis ： take Symbol reference Replace with direct reference , This stage will put some static methods ( Symbol reference , such as main() Method ) Replace with a pointer or handle to the memory where the data is located ( Direct reference ), This is called static linking The process ( Finished during class loading ), Dynamic links It's done during the running of the program, replacing symbol references with direct references .

initialization ： Initialize assignment to class variable , And execute the static code block .

Two 、 Class loader

 JVM There are mainly four types of loaders to complete the class loading of .

Boot class loader （BootstrapClassLoad）： Responsible for loading supports JVM The location of the operation is JRE Of lib The core class library under the directory , such as rt.jar、charsets.jar etc. . To avoid tampering with the core class library , This kind of core class library can only be loaded by the bootstrap class loader , Even if the user-defined class loading specifies to load the classes under this path, an error will be reported and the loading will not succeed . The boot class loader consists of C++ Code implementation , therefore , stay JAVA The reference value to it in the program is null.

Extend the classloader （ExtClassLoad）： Responsible for loading supports JVM The location of the operation is JRE Of lib In the catalog ext Expand... In the directory JAR Class package .

Application class loader （AppClassLoad）： Responsible for loading ClassPath Class package under path , The main thing is to load the classes you write .

Custom loader ： Responsible for loading the class package under the user-defined path . Custom loaders need to inherit ClassLoad class , meanwhile , You can decide whether to reload the class according to your business needs loadClass and findClass Method .

Class loaders form from top to bottom " Father and son ", Be careful , There is a in the loader class parent The value of the property is the upper classloader object , Is not JAVA Class inheritance at level .

3、 ... and 、 Class loading mechanism

JVM The class loading mechanism of is a parental delegation mechanism , When loading a class , If you use a custom class loader , Then check whether the custom loader has loaded this class , If not, delegate the upper application class loader to load , At loading time , Similarly, check whether the current class loader has loaded this class , If not, delegate the upper extension class loader to load . At loading time , Similarly, check whether the current class loader has loaded this class , If not, it will be loaded by the upper boot class loader , At loading time , Similarly, check whether the current class loader has loaded this class , without , The boot class loader loads this class , If the class is not loaded under the path governed by the boot class loader , There is a lower level extension program class loader to load , If the class is not loaded under the path governed by the extended class loader , There is a lower level application class loader to load ; If the class is not loaded under the path governed by the application class loader , There is a lower level custom class loader to load ; If it cannot be loaded again, an exception will be thrown . It can be summed up as a sentence : Check whether the class has been loaded from the bottom up , Load classes from top to bottom .

  Four 、 The significance of parental delegation mechanism

    Sandbox security mechanism ： Each class loader manages the loading of classes under its own path , For example, the core class library can only be loaded by the boot class loader , It can prevent the core class library from being tampered with . Write a class name that is exactly the same as the core class library 、 Name of package Object、String class , Will not be loaded successfully .

    Avoid duplicate loading of classes ： When the father has loaded the class , There is no need ClassLoader Load one more Time , Ensure the uniqueness of the loaded class .

    Improve class loading efficiency ： Because in the application ,90% The above classes are written by programmers themselves , So checking from bottom to top can improve the efficiency of class loading .

5、 ... and 、 Overall responsibility for the delegation mechanism

“ Overall responsible for ” It means to be a ClassLoder A class load , Unless the one shown uses another ClassLoder, This kind

The dependent and referenced classes are also created by this ClassLoder As an entrance load , It triggers class loading .

6、 ... and 、Tomcat Break the parental delegation mechanism

   tomcat Why not use a parental delegation mechanism ？

    One tomcat It is possible to run multiple applications , And the multiple applications refer to different versions of the same class , therefore , The feature of ensuring that the class only loads one copy from the parent delegation mechanism does not conform to tomcat Business scenario requirements .

   tomcat How to ensure jps Hot loading of ？   

    Every jsp The file corresponds to a unique classloader , When one jsp The file has been modified , Just uninstall this jsp Class loader . Recreate class loader , Reload jsp file

   tomcat Several main class loaders for ：

commonLoader：Tomcat The most basic classloader , Load... In the path class Can be Tomcat The container itself and the individual Webapp visit ;

catalinaLoader：Tomcat Container private classloader , Load... In the path class about Webapp No so ;

sharedLoader： each Webapp Shared classloader , Load... In the path class For all Webapp so , But for Tomcat The container is not visible ;

WebappClassLoader： each Webapp Private classloader , Load... In the path class Only for the present Webapp so , Such as loading war Related classes in the package , Every war Package applications have their own WebappClassLoader, Achieve mutual isolation , Like different war Package applications introduce different spring edition , So that the implementations can load their own spring edition ;

Be careful ： The same JVM Inside , Two class objects with the same package name and class name can coexist , Because their classloaders can be different （ The same classloader Class, The two classloader instances are also called different ）, So see if the two class objects are the same , In addition to seeing whether the package name and class name of the class are the same , They also need the same classloader object to be considered the same .