Tomcat class loader implementation method and example code

Tomcat defines multiple ClassLoaders internally so that applications and containers can access classes and resources in different repositories, while achieving class isolation between applications.

1. Java class loading mechanism

Class loading is to load the compiled class files into the JVM memory (permanent generation/metaspace).

The reason why class loaders can achieve class isolation is that two classes are equal only if they are loaded by the same class loader, otherwise they must be unequal.

When loading, JVM uses a parent delegation mechanism. When the class loader wants to load a class, the loading order is:

First, the request is delegated to the parent loader. If the parent loader cannot find the class to be loaded, it will then look for its own repository to try to load it.

The advantage of this mechanism is that it can ensure that the core class library is not overwritten.

According to the Servlet specification, the Webapp loader is slightly different. It will first search in its own resource library instead of delegating upward, breaking the standard delegation mechanism. Let's take a look at the design and implementation of Tomcat.

2. Tomcat class loader design

The overall class loader structure of Tomcat is as follows:

The class loaders provided by JDK are:

Bootstrap - Bootstrap class loader, part of JVM, loads specific files in the <JAVA_HOME>/lib/ directory Extension - Extension class loader, loads class libraries in the <JAVA_HOME>/lib/ext/ directory Application - Application class loader, also called system class loader, loads class libraries specified by CLASSPATH

The class loaders that Tomcat implements are:

Common - The parent loader is AppClassLoader, which loads the class libraries in the ${catalina.home}/lib/ directory by default. Catalina - The parent loader is the Common class loader, which loads the resources configured by server.loader in the catalina.properties configuration file, which are generally the resources used internally by Tomcat. Shared - The parent loader is the Common class loader, which loads the resources configured by shared.loader in the catalina.properties configuration file, which are generally the resources shared by all Web applications. WebappX - The parent loader is the Shared loader, which loads the classes in /WEB-INF/classes and the jar packages in /WEB-INF/lib/. JasperLoader - The parent loader is the Webapp loader, which loads the class files generated by compiling JSP applications in the work directory.

In implementation, the above diagram is not an inheritance relationship, but a parent-child relationship through combination. Source code class diagram of Tomcat class loader:

Common, Catalina, and Shared are all instances of StandardClassLoader. By default, they refer to the same object. There is no difference between StandardClassLoader and URLClassLoader; WebappClassLoader searches and loads in the following order according to the specification:

Loaded from the Bootstrap repository inside the JVM Loaded from the application loader path, that is, CLASSPATH Loaded from the /WEB-INF/classes directory in the Web program From the jar file in /WEB-INF/lib in the Web program Loaded from the container Common loader repository, that is, the resources shared by all Web programs

Next, let’s look at the source code implementation.

3. Initialization of custom loader

The common class loader is initialized in initClassLoaders of Bootstrap. The source code is as follows:

private void initClassLoaders() {
 try {
 commonLoader = createClassLoader("common", null);
 if( commonLoader == null ) {
  // no config file, default to this loader - we might be in a 'single' env.
  commonLoader=this.getClass().getClassLoader();
 }
 //Specify the repository path configuration file prefix and parent loader, create a ClassLoader instance catalinaLoader = createClassLoader("server", commonLoader);
 sharedLoader = createClassLoader("shared", commonLoader);
 } catch (Throwable t) {
 log.error("Class loader creation threw exception", t);
 System.exit(1);
 }
}

You can see that three class loaders are created. CreateClassLoader obtains the resource warehouse address according to the configuration and finally returns a StandardClassLoader instance. The core code is as follows:

private ClassLoader createClassLoader(String name, ClassLoader parent)
 throws Exception {

 String value = CatalinaProperties.getProperty(name + ".loader");
 if ((value == null) || (value.equals("")))
  return parent; // If not configured, return the passed parent loader ArrayList repositoryLocations = new ArrayList();
 ArrayList repositoryTypes = new ArrayList();
 ...
 // Get the resource repository path String[] locations = (String[]) repositoryLocations.toArray(new String[0]);
 Integer[] types = (Integer[]) repositoryTypes.toArray(new Integer[0]);
 // Create a StandardClassLoader object ClassLoader classLoader = ClassLoaderFactory.createClassLoader
   (locations, types, parent);
 ...
 return classLoader;
}

After the class loader is initialized, a Catalina object will be created, and its load method will eventually be called to parse server.xml and initialize the internal components of the container. So how does a container, such as Engine, relate to the parent loader of this setting?

The Catalina object has a parentClassLoader member variable, which is the parent loader of all components. The default is AppClassLoader. When this object is created, its setParentClassLoader method is reflected and the parent loader is set to sharedLoader.

When the top-level container Engine in Tomcat is initialized, Digester has a SetParentClassLoaderRule rule, which associates Catalina's parentClassLoader through the Engine.setParentClassLoader method.

4. How to break the parent delegation mechanism

The answer is to use Thread.getContextClassLoader() - the context loader for the current thread, which can be set dynamically while your code is running via Thread.setContextClassLoader().

By default, the Thread context loader is inherited from the parent thread, which means that the default context loader of all threads is the same as the first started thread, that is, the main thread, and its context loader is AppClassLoader.

When StandardContext is started, Tomcat first initializes a WebappClassLoader and then sets it as the context loader of the current thread. Finally, it encapsulates it as a Loader object and uses it when loading Servlet classes with the help of the parent-child relationship between containers.

5. Class loading for web applications

The class loading of the Web application is completed by the WebappClassLoader method loadClass(String, boolean). The core code is as follows:

Preventing overwriting J2SE

public synchronized Class loadClass(String name, boolean resolve)
 throws ClassNotFoundException {
 ...
 Class clazz = null;
 // (0) Check if it has been loaded in its internal cache clazz = findLoadedClass0(name);
 if (clazz != null) {
 if (log.isDebugEnabled())
  log.debug("Returning class from cache");
 if (resolve) resolveClass(clazz);
 return (clazz);
 }
 // (0.1) Check if it is already loaded in the JVM cache clazz = findLoadedClass(name);
 if (clazz != null) {
 if (log.isDebugEnabled())
  log.debug("Returning class from cache");
 if (resolve) resolveClass(clazz);
 return (clazz);
 }
 // (0.2) Try to use the system class loader to prevent overwriting the J2SE class try {
 clazz = system.loadClass(name);
 if (clazz != null) {
  if (resolve) resolveClass(clazz);
  return (clazz);
 }
 } catch (ClassNotFoundException e) { // Ignore }
 // (0.5) Use SecurityManager to check if you have access to this class if (securityManager != null) {
 int i = name.lastIndexOf('.');
 if (i >= 0) {
  try {
  securityManager.checkPackageAccess(name.substring(0,i));
  } catch (SecurityException se) {
  String error = "Security Violation, attempt to use " +
   "Restricted Class: " + name;
  log.info(error, se);
  throw new ClassNotFoundException(error, se);
  }
 }
 }
 boolean delegateLoad = delegate || filter(name);
 // (1) Whether to delegate to the parent class, the default value here is false
 if (delegateLoad) {
  ...
 }
 // (2) Try to find your own repository and load it try {
 clazz = findClass(name);
 if (clazz != null) {
  if (log.isDebugEnabled())
  log.debug(" Loading class from local repository");
  if (resolve) resolveClass(clazz);
  return (clazz);
 }
 } catch (ClassNotFoundException e) {}
 // (3) If loading still fails at this point, delegate the loading request to the parent loader if (!delegateLoad) {
 if (log.isDebugEnabled())
  log.debug(" Delegating to parent classloader at end: " + parent);
 ClassLoader loader = parent;
 if (loader == null)
  loader = system;
 try {
  clazz = loader.loadClass(name);
  if (clazz != null) {
  if (log.isDebugEnabled())
   log.debug(" Loading class from parent");
  if (resolve) resolveClass(clazz);
  return (clazz);
  }
 } catch (ClassNotFoundException e) {}
 }
 //Finally, the loading fails and an exception is thrown throw new ClassNotFoundException(name);
}

When preventing J2SE classes from being overwritten, Tomcat 6 uses AppClassLoader. The rt.jar core class library is loaded by the Bootstrap Classloader, but this loader is not available in Java code. The following optimizations are made in higher versions:
ClassLoader j = String.class.getClassLoader();
if (j == null) {
 j = getSystemClassLoader();
 while (j.getParent() != null) {
 j = j.getParent();
 }
}
this.javaseClassLoader = j;

When loading classes, Tomcat 6 uses AppClassLoader. The rt.jar core class library is loaded by Bootstrap Classloader, but this loader cannot be obtained in Java code. The following optimizations are made in higher versions:

ClassLoader j = String.class.getClassLoader();
if (j == null) {
 j = getSystemClassLoader();
 while (j.getParent() != null) {
 j = j.getParent();
 }
}
this.javaseClassLoader = j;

That is, use a class loader that is as close as possible to the Bootstrap loader.

6. Summary

I believe most people have encountered the ClassNotFoundException exception. Behind this is the class loader. Having a certain understanding of the loading principle will help troubleshoot the problem.

The above is the implementation method and example code of Tomcat class loader introduced by the editor. I hope it will be helpful to everyone. If you have any questions, please leave me a message and the editor will reply to you in time. I would also like to thank everyone for their support of the 123WORDPRESS.COM website!
If you find this article helpful, please feel free to reprint it and please indicate the source. Thank you!