Tomcat's class loading mechanism process and source code analysis

Preface

In the previous Java Virtual Machine: Object Creation Process and Class Loading Mechanism, Parent Delegation Model article, we introduced the JVM class loading mechanism and parent delegation model. The class loading process of the parent delegation model is mainly divided into the following steps:

(1) When initializing ClassLoader, you need to specify who your parent is

(2) First check whether the class has been loaded. If the class has been loaded, return directly

(3) If not loaded, call the loadClass() method of the parent loader parent to load it

(4) If the parent loader is empty, the bootstrap ClassLoader is used by default to load

(5) If the parent class fails to load, a ClassNotFoundException is thrown, and then the findClass() method is called to load it.

As mentioned in the previous article, if you want to destroy this mechanism, you can customize a class loader (inherited from ClassLoader) and rewrite the loadClass() method in it so that it does not perform parent delegation. The most classic example is the class loading mechanism of the Tomcat container, which implements its own class loader WebApp ClassLoader and breaks the parent delegation model. After each application is deployed, a unique class loader is created.

1. Tomcat class loader structure diagram:

(1) Common ClassLoader: loads the jar under the common.loader property, usually in the CATALINA_HOME/lib directory, mainly used by Tomcat and some common classes of applications

(2) Catalina ClassLoader: Loads the jar under the server.loader property. By default, no path is configured and returns its parent loader, Common ClassLoader. It mainly loads visible classes inside the server. These classes cannot be accessed by applications.

(3) Shared Classloader: loads the jar under the share.loader attribute. By default, no path is configured and returns its parent loader, Common ClassLoader. It is mainly used to load application shared classes. These classes are not visible to Tomcat itself.

Only after specifying the server.loader and share.loader items in the tomcat/conf/catalina.properties configuration file, will the instances of Catalina ClassLoader and Shared ClassLoader be actually created. Otherwise, the instances of Common ClassLoader will be used instead of these two class loaders. However, these two loader items are not set in the default configuration file.

(4) WebApp ClassLoader: Tomcat can have multiple WebApp ClassLoader instances. Each application will have a unique WebApp ClassLoader to load the classes under /WEB-INF/classes and /WEB-INF/lib of the application.

2. Description of Tomcat's class loading process:

When Tomcat uses WebAppClassLoader for class loading, the specific process is as follows:

(1) First check whether the class has been loaded in the local cache to see if Tomcat has loaded the class.

(2) If Tomcat has not loaded this class, it will check the cache of the system class loader to see if it has been loaded.

(3) If not, use the ExtClassLoader class loader to load the class. Here comes the point. Tomcat's WebAppClassLoader does not use AppClassLoader to load the class first, but directly uses ExtClassLoader to load the class. However, ExtClassLoader still follows parent delegation. It will use Bootstrap ClassLoader to load classes, ensuring that the core classes in Jre will not be loaded repeatedly.

For example, loading an Object class in the Web. WebAppClassLoader → ExtClassLoader → Bootstrap ClassLoader, this loading chain ensures that the Object will not be loaded repeatedly.

(4) If loading is not successful, WebAppClassLoader will call its own findClass() method to load the class by itself, first loading it from WEB-INF/classes and then from WEB-INF/lib.

(5) If loading is still unsuccessful, WebAppclassLoader will delegate to SharedClassLoader, SharedClassLoader will delegate to CommonClassLoader, CommonClassLoader will delegate to AppClassLoader, until it is finally delegated to BootstrapClassLoader, and finally load the class layer by layer in its own directory.

(6) If none of the files are loaded successfully, an exception is thrown.

3. Source code analysis:

(1) WebAppClassLoader's loadClass() method source code:

WebappClassLoader application class loader loadClass in its parent class WebappClassLoaderBase

public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class<?> clazz = null;
        //1. First check in the local cache whether the class has been loaded clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }
        //2. Check whether the system class loader has loaded clazz = findLoadedClass(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }
        // 3. Try to load the class with ExtClassLoader class loader (ExtClassLoader obeys parent delegation, ExtClassLoader will use Bootstrap ClassLoader to load the class)
        ClassLoader javaseLoader = getJavaseClassLoader();
        try {
            clazz = javaseLoader.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }
        // 4. Try to search for the class in the local directory and load it try {
            clazz = findClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }
        // 5. Try to load with the system class loader (AppClassLoader) try {
            clazz = Class.forName(name, false, parent);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }
     }
    //6. The above processes all fail to load and throw an exception throw new ClassNotFoundException(name);
}

(2) WebAppClassLoader's findClass() method source code:

public Class<?> findClass(String name) throws ClassNotFoundException {
    // Ask our superclass to locate this class, if possible
    // (throws ClassNotFoundException if it is not found)
    Class<?> clazz = null;
 
    // First search for the class in your own Web application directory
    clazz = findClassInternal(name);
 
    // Can't find it and let the parent class handle it if ((clazz == null) && hasExternalRepositories) {  
        clazz = super.findClass(name);
    }
    if (clazz == null) {
         throw new ClassNotFoundException(name);
    }
    return clazz;
}

4. Why does Tomcat implement its own class loading mechanism?

When WebAppClassLoader loads classes, it deliberately breaks the JVM parent delegation mechanism, bypasses AppClassLoader, and directly uses ExtClassLoader to load classes. The main reason is to ensure that the class libraries used by different Web applications deployed on the same Web container can be isolated from each other to avoid mutual influence between different projects. Of course there are other reasons, such as:

(1) Ensure that the security of the Web container itself is not affected by the deployed Web application, so the class library used by Tomcat must be independent of the class library of the deployed application.

(2) Ensure that some basic classes are not loaded at the same time. Some class libraries can be shared between Tomcat and deployed applications, such as servlet-api

(3) Ensure that class libraries can be shared between applications deployed in the same Web container. This sounds like the main reasons are contradictory, but in fact it is very reasonable. After the class is loaded into the virtual machine by the class loader, it will be stored in the permanent generation of the method area. If the class library cannot be shared, the method area of ​​the virtual machine will easily be at risk of excessive expansion. For example, if a large number of applications are managed by Spring, and if the Spring class library cannot be shared, the Spring class library of each application will be loaded once, which will be a huge waste of resources.

Summary: In Tomcat, only the WebAppClassLoader loader breaks parent delegation, while other class loaders still follow parent delegation. The main reason for doing this is to ensure that the class libraries used by different Web applications in the same Web container are independent of each other to avoid mutual interference.

Reference article: https://www.jb51.net/article/229561.htm

This is the end of this article about Tomcat's class loading mechanism process and source code analysis. For more relevant Tomcat class loading mechanism content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!