Java Class Loader
The class loader is responsible for loading class data from bytecode files into the JVM, performing verification, parsing, and initialization of the data, ultimately forming Java types that can be directly used by the JVM.
In general web development, we rarely use class loaders directly because web containers shield us from their complexity - we only need to focus on implementing business logic. However, if you’ve developed Java middleware, you’ll find class loaders are used very frequently.
This chapter first introduces the ClassLoader API and its usage, then sequentially covers the ClassLoader source code, JDK and web middleware class loaders, and finally explains the implementation principles of hot loading technology.
4.1 ClassLoader API
ClassLoader is an abstract class that cannot be used directly, so we need to extend it and override its methods. Its main methods include defineClass, loadClass, findClass, resolveClass and their overloaded versions. The key method definitions are as follows:
// Takes a byte array of bytecode as input and outputs a Class object - its purpose is to parse the byte array into a Class object protected final Class<?> defineClass(String name, byte[] b, int off, int len)
// Finds a Class object by class name public Class<?> loadClass(String name)
// Locates a class by name protected Class<?> findClass(String name)
// Called after class loading to complete class linking protected final void resolveClass(Class<?> c)Let’s first implement a simple NetworkClassLoader that has the capability to load class files from the network. The implementation code is as follows:
import java.io.ByteArrayOutputStream;import java.io.IOException;import java.io.InputStream;import java.net.URL;
public class NetworkClassLoader extends ClassLoader {
// Download URL private String downloadUrl;
public NetworkClassLoader(String downloadUrl) { this.downloadUrl = downloadUrl; }```java // Implementing the class lookup method @Override public Class findClass(String name) { byte[] b = loadClassData(name); return defineClass(name, b, 0, b.length); }
// Downloads the class file from remote to obtain the bytecode array private byte[] loadClassData(String name) { // load the class data from the connection // ... }
// Converts class name to server download path private String classNameToPath(String name) { return downloadUrl + "/" + name.replace(".", "/") + ".class"; }
// Test method public class Main { public static void main(String[] args) throws Exception { // Download URL String baseUrl = "https://wwww.jrasp.com"; // Initialize network class loader NetworkClassLoader loader = new NetworkClassLoader(baseUrl); // Load class located at https://wwww.jrasp.com/Foo.class and create instance Object foo = loader.loadClass("Foo").newInstance(); } }}The loaded class Foo is a simple class that outputs “create new instance” when creating an instance object. The code for class Foo is as follows:
public class Foo { public Foo() { System.out.println("create new instance"); }}// Running the Main method produces the following output:// create new instanceThe main functions of ClassLoader are class lookup, loading and linking. In addition to loading classes, class loaders are also responsible for loading resources such as configuration files or images.
4.2 ClassLoader Source Code Analysis
With the above usage foundation, let’s analyze the source code of the class loader and its important implementation classes.
4.2.1 loadClass
ClassLoader calls its loadClass method to load classes. The core code of loadClass is as follows:
Code location: src/java.base/share/classes/java/lang/ClassLoader.java```java protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { // If the parent class loader is not null, attempt to load from parent c = parent.loadClass(name, false); } else { // If parent loader is null, use bootstrap class loader c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // Ignore exception and continue searching } if (c == null) { // If parent loaders fail, call the overridden findClass method of current ClassLoader c = findClass(name); } } // Link the class if (resolve) { resolveClass(c); } return c; } }
The class loading sequence above can be summarized as: first attempt to load via parent loader (if parent loader is null, use the system bootstrap class loader), and only when all parent loaders fail will it delegate to the current ClassLoader's overridden findClass method. As shown in Figure 4-1:
> Figure 4-1 Class Loader Delegation Model
### 4.2.2 findClassDuring class loading, if all parent loaders fail to find the class, the overridden findClass method of the child class loader will be invoked. The findClass method is as follows:
> Code location: src/java.base/share/classes/java/lang/ClassLoader.java```javaprotected Class<?> findClass(String name) throws ClassNotFoundException { // Throws exception when called throw new ClassNotFoundException(name);}As we can see, this method throws an exception, so it cannot be called directly and requires subclass implementation. URLClassLoader is a subclass of ClassLoader and overrides the findClass method. The properties and constructor of URLClassLoader are as follows:
Code location: src/java.base/share/classes/java/net/URLClassLoader.java
// Search path for classes and resourcesprivate final URLClassPath ucp;
public URLClassLoader(URL[] urls, ClassLoader parent) { // Specify parent class loader super(parent); // ... Permission check code omitted this.acc = AccessController.getContext(); // Initialize ucp property ucp = new URLClassPath(urls, acc);}Implements the findClass method of ClassLoader to load classes from specified paths.
Code location: src/java.base/share/classes/java/net/URLClassLoader.java
protected Class<?> findClass(final String name) throws ClassNotFoundException { // 1. Convert fully qualified class name to .class file path format String path = name.replace('.', '/').concat(".class"); // 2. Check if it exists in URLClassPath Resource res = ucp.getResource(path, false); // ... Exception handling omitted return defineClass(name, res);}The execution logic of URLClassLoader’s findClass method mainly consists of three steps:
- Convert the fully qualified class name to .class file path format;
- Check if the file exists in URLs;
- Call defineClass to complete class linking and initialization;
4.2.3 defineClass
defineClass is used together with findClass. findClass is responsible for reading bytecode from disk or network, while defineClass parses the bytecode into a Class object. The defineClass method uses resolveClass to complete the linking of the Class. The source code is as follows:
Code location: src/java.base/share/classes/java/lang/ClassLoader.java```java protected final Class defineClass(String name, byte[] b, int off, int len, ProtectionDomain protectionDomain) throws ClassFormatError { protectionDomain = preDefineClass(name, protectionDomain); String source = defineClassSourceLocation(protectionDomain); // Call native method to complete linking Class c = defineClass1(name, b, off, len, protectionDomain, source); postDefineClass(c, protectionDomain); return c; }
The implementation of `defineClass` lies in the `defineClass1` method, which is a native method with its specific implementation in HotSpot. The implementation is quite complex and generally doesn't require special attention.
The steps required when a ClassLoader loads a class file into the JVM are shown in Figure 4-2 below:
> Figure 4-2 Phases of JVM Class Loading
Typically, we only need to override the `findClass` method of ClassLoader to obtain the bytecode of the class to be loaded, then call the `defineClass` method to generate the Class object. If you want the class to be linked immediately when loaded into the JVM, you can call the `resolveClass` method, or leave it to the JVM to link during class initialization.
## 4.3 JDK's Class Loaders
JDK's own jar packages such as rt.jar and tools.jar (or modules in JDK9+) also require class loaders for loading. The following code demonstrates how to obtain JDK's built-in class loaders:```javapublic class JdkClassloader { public static void main(String[] args) { // Get system class loader ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader(); System.out.println(systemClassLoader);
// Get parent of system class loader --> extension class loader or platform class loader ClassLoader platformClassLoader = systemClassLoader.getParent(); System.out.println(platformClassLoader);
// Get parent of extension class loader --> bootstrap class loader (C/C++) ClassLoader bootstrapClassLoader = platformClassLoader.getParent(); System.out.println(bootstrapClassLoader); }}```Running on JDK8:sun.misc.Launcher$AppClassLoader@18b4aac2 sun.misc.Launcher$ExtClassLoader@4a574795 null
Running on JDK11:jdk.internal.loader.ClassLoaders$AppClassLoader@512ddf17 jdk.internal.loader.ClassLoaders$PlatformClassLoader@3cda1055 null
As shown, there are differences in the class names of class loaders between JDK8 and JDK11. The implementations are explained separately below.
### 4.3.1 JDK8 Class Loaders
#### 4.3.1.1 AppClassLoaderAppClassLoader, also known as System ClassLoader, extends URLClassLoader. It is one of the default class loaders in the JVM, primarily used to load user classes and third-party dependency packages. The loading path can be specified via the `-Djava.class.path` parameter in the JVM startup command.> Code location: src/share/classes/sun/misc/Launcher$AppClassLoader.java
```java// AppClassLoader extends URLClassLoaderstatic class AppClassLoader extends URLClassLoader {
public static ClassLoader getAppClassLoader(final ClassLoader extcl) throws IOException { // Search path java.class.path final String s = System.getProperty("java.class.path"); final File[] path = (s == null) ? new File[0] : getClassPath(s);
URL[] urls = (s == null) ? new URL[0] : pathToURLs(path); return new AppClassLoader(urls, extcl); }
AppClassLoader(URL[] urls, ClassLoader parent) { super(urls, parent, factory); }
// Overrides loadClass public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { // Calls parent URLClassLoader to complete class loading return (super.loadClass(name, resolve)); }
// Other methods omitted...}4.3.1.2 ExtClassLoader
The ExtClassLoader, known as the Extension ClassLoader, inherits from URLClassLoader and is primarily responsible for loading Java’s extension libraries. By default, it loads all JAR packages in the ${JAVA_HOME}/jre/lib/ext/ directory. Its search path can also be configured using the -Djava.ext.dirs parameter.
Code location: src/share/classes/sun/misc/Launcher$ExtClassLoader.java
// ExtClassLoader inherits from URLClassLoaderstatic class ExtClassLoader extends URLClassLoader {
public static ExtClassLoader getExtClassLoader() throws IOException { final File[] dirs = getExtDirs();
try { return new ExtClassLoader(dirs); } catch (java.security.PrivilegedActionException e) { throw (IOException) e.getException(); } }
public ExtClassLoader(File[] dirs) throws IOException { super(getExtURLs(dirs), null, factory); }
private static File[] getExtDirs() { // Specify the loading path through system properties String s = System.getProperty("java.ext.dirs"); File[] dirs; if (s != null) { StringTokenizer st = new StringTokenizer(s, File.pathSeparator); int count = st.countTokens(); dirs = new File[count]; for (int i = 0; i < count; i++) { dirs[i] = new File(st.nextToken()); } } else { dirs = new File[0]; } return dirs; }}The inheritance relationship of class loaders in JDK8 is shown in Figure 4-3 below:
Figure 4-3: Inheritance Relationship of Class Loaders in JDK8
4.3.1.3 Initialization of Class Loaders in JDK8
The initialization of JDK’s class loaders is implemented in the Launcher class.
Source location: src/share/classes/sun/misc/Launcher.java
public class Launcher {``` public Launcher() { // Create ExtClassLoader ClassLoader extcl = ExtClassLoader.getExtClassLoader(); // Create AppClassLoader ClassLoader loader = AppClassLoader.getAppClassLoader(extcl); // Set current thread's ContextClassLoader Thread.currentThread().setContextClassLoader(loader); // Exception handling code omitted } // ...}As can be seen, the initialization process is relatively simple: first initialize the ExtClassLoader, then initialize the AppClassLoader, and set the AppClassLoader’s parent loader as ExtClassLoader.
4.3.2 Class Loaders in JDK11
After implementing modularization in JDK9, some modifications were made to Classloader, one of which was changing ExtClassLoader to PlatformClassLoader. With modularization, different Classloaders load their corresponding modules. Since JDK11 is a long-term supported stable version, we use JDK11’s source code to illustrate the changes in class loaders. The inheritance relationship of class loaders in JDK11 is shown in Figure 4-4 below:
Figure 4-4 Inheritance relationship of class loaders in JDK11
4.3.2.1 BuiltinClassLoader
BuiltinClassLoader is the parent class of PlatformClassLoader, BootClassLoader, and AppClassloader. Functionally similar to URLClassLoader, it implements class lookup based on UrlClassPath, but BuiltinClassLoader also supports loading classes from modules.
The properties and constructor of BuiltinClassLoader are as follows:
Code location: src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
// Class loader pathprivate final URLClassPath ucp;
BuiltinClassLoader(String name, BuiltinClassLoader parent, URLClassPath ucp) { // Ensure returning null when parent loader is bootloader // name is the name of the class loader super(name, parent == null || parent == ClassLoaders.bootLoader() ? null : parent);
this.parent = parent; this.ucp = ucp;
this.nameToModule = new ConcurrentHashMap<>(); this.moduleToReader = new ConcurrentHashMap<>();}```The `BuiltinClassLoader` also overrides the `loadClass` method, which actually calls the `loadClassOrNull` method. Let's examine the implementation of the `loadClassOrNull` method.
> Source location: src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java```javaprotected Class<?> loadClassOrNull(String cn, boolean resolve) { // Lock to ensure thread safety synchronized (getClassLoadingLock(cn)) { // First check if the class has already been loaded (this is a native method in ClassLoader) Class<?> c = findLoadedClass(cn); if (c == null) { // Need to load module information first LoadedModule loadedModule = findLoadedModule(cn); if (loadedModule != null) { BuiltinClassLoader loader = loadedModule.loader(); if (loader == this) { if (VM.isModuleSystemInited()) { c = findClassInModuleOrNull(loadedModule, cn); } } else { // Delegate to another class loader c = loader.loadClassOrNull(cn); } } else { // First try to load using the parent loader if (parent != null) { c = parent.loadClassOrNull(cn); }
// If still not loaded, use the current loader if (c == null && hasClassPath() && VM.isModuleSystemInited()) { // This method internally calls defineClass to complete class definition c = findClassOnClassPathOrNull(cn); } }
}
if (resolve && c != null) resolveClass(c);``` return c; }}There is a slight difference from the usual parent delegation. If a class belongs to a module, the module’s class loader will be directly invoked to load it, rather than using the parent delegation model of the current class loader. However, once the corresponding class loader for this class is found, parent delegation will still be followed for the loading process.
BuiltinClassLoader also overrides the findClass method of ClassLoader.
Source location:
src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
@Overrideprotected Class<?> findClass(String cn) throws ClassNotFoundException {
// Attempt to find in modules LoadedModule loadedModule = findLoadedModule(cn);
Class<?> c = null; if (loadedModule != null) { // Delegate loading task to the module's loader if (loadedModule.loader() == this) { c = findClassInModuleOrNull(loadedModule, cn); } } else { // Search in classpath if (hasClassPath()) { c = findClassOnClassPathOrNull(cn); } }
// If not found, throw exception if (c == null) throw new ClassNotFoundException(cn);
return c;}Here, findClassOnClassPathOrNull searches for the class in the classpath.
Source location:
src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
private Class<?> findClassOnClassPathOrNull(String cn) { String path = cn.replace('.', '/').concat(".class"); // Permission check code omitted... Resource res = ucp.getResource(path, false); if (res != null) { try { return defineClass(cn, res); } catch (IOException ioe) { // TBD on how I/O errors should be propagated } } return null;}4.3.2.2 Subclasses of BuiltinClassLoader and Initialization
The ClassLoaders class initializes the BootClassLoader, PlatformClassLoader, and AppClassLoader class loaders respectively.> Source location: src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java
public class ClassLoaders {
// JDK built-in class loaders private static final BootClassLoader BOOT_LOADER; private static final PlatformClassLoader PLATFORM_LOADER; private static final AppClassLoader APP_LOADER;
// Initialize class loader objects static { // Can be specified using -Xbootclasspath/a or Boot-Class-Path attribute in -javaagent String append = VM.getSavedProperty("jdk.boot.class.path.append"); // Initialize BOOT_LOADER BOOT_LOADER = new BootClassLoader((append != null && append.length() > 0) ? new URLClassPath(append, true) : null);
// Initialize PLATFORM_LOADER and set BOOT_LOADER as parent of AppClassLoader PLATFORM_LOADER = new PlatformClassLoader(BOOT_LOADER);
// Get classpath String cp = System.getProperty("java.class.path"); if (cp == null || cp.length() == 0) { String initialModuleName = System.getProperty("jdk.module.main"); cp = (initialModuleName == null) ? "" : null; } URLClassPath ucp = new URLClassPath(cp, false); // Initialize APP_LOADER and set PLATFORM_LOADER as parent of AppClassLoader APP_LOADER = new AppClassLoader(PLATFORM_LOADER, ucp); }
// ... }From the initialization code of the class loader instances, we can see that BootClassLoader is used to load classes specified by the jdk.boot.class.path.append parameter. During PLATFORM_LOADER initialization, BOOT_LOADER is set as its parent, and during AppClassLoader initialization, PLATFORM_LOADER is set as its parent, forming a three-tier class loader structure.
Now let’s look at the PlatformClassLoader class which is specific to JDK9 and above:```java private static class PlatformClassLoader extends BuiltinClassLoader {
PlatformClassLoader(BootClassLoader parent) { // The class loader name is "platform" super("platform", parent, null);}
// ...}
Different class loaders are responsible for loading corresponding modules, which are specified during JDK compilation.> Source: jdk11-1ddf9a99e4ad/make/common/Modules.gmk
+ BOOT_MODULES are modules defined by the bootstrap loader:```textjava.base java.datatransferjava.desktop java.instrumentjava.logging java.managementjava.management.rmi java.namingjava.prefs java.rmijava.security.sasl java.xmljdk.internal.vm.ci jdk.jfrjdk.management jdk.management.jfrjdk.management.agent jdk.netjdk.sctp jdk.unsupportedjdk.naming.rmi- PLATFORM_MODULES are modules defined by the platform loader:
java.net.http java.scriptingjava.security.jgss java.smartcardiojava.sql java.sql.rowsetjava.transaction.xa java.xml.cryptojdk.accessibility jdk.charsetsjdk.crypto.cryptoki jdk.crypto.ecjdk.dynalink jdk.httpserverjdk.jsobject jdk.localedatajdk.naming.dns jdk.scripting.nashornjdk.security.auth jdk.security.jgssjdk.xml.dom jdk.zipfsjdk.crypto.mscapi jdk.crypto.ucryptojava.compiler jdk.aotjdk.internal.vm.compilerjdk.internal.vm.compiler.managementjava.se- JRE_TOOL_MODULES are tools included in JRE, loaded by AppClassLoader:
jdk.jdwp.agentjdk.packjdk.scripting.nashorn.shellOther modules not listed are loaded by AppClassLoader.## 4.4 Web Container Class Loaders
The previous section introduced the general class loading model in Java: the Parent Delegation Model, which applies to most class loading scenarios. However, this model is not suitable for web containers because the Servlet specification imposes certain requirements on web container class loading. The main rules are as follows:
- Classes under WEB-INF/classes and WEB-INF/lib take precedence over classes from the parent container. For example, if there is a Foo class in WEB-INF/classes and another Foo class in CLASSPATH, the web container loader will prioritize loading the class from WEB-INF/classes. This behavior is contrary to the Parent Delegation Model.
- System classes like java.lang.Object do not follow the first rule. Classes in WEB-INF/classes or WEB-INF/lib cannot replace system classes. The specification does not explicitly define which classes are considered system classes, but web containers typically determine them by enumerating certain classes.
- The implementation classes of the web container itself cannot be referenced by application classes, meaning no application class loader can load the web container’s implementation classes. The web container identifies its own classes by enumerating package names.
4.4.1 Jetty Class Loader
To meet these three requirements and achieve dependency isolation between different deployed applications, Jetty defines its own class loader called WebAppClassLoader. The inheritance relationship of this class loader is shown below:
Figure 4-5 Inheritance Relationship of Jetty Class Loaders
The attributes of WebAppClassLoader are as follows:
// Class loader contextprivate final Context _context;// Parent loaderprivate final ClassLoader _parent;// File extensions to load (.zip or .jar)private final Set<String> _extensions = new HashSet<String>();// Loader nameprivate String _name = String.valueOf(hashCode());// Pre-class-loading transformersprivate final List<ClassFileTransformer> _transformers = new CopyOnWriteArrayList<>();Classes whose package path names are included in the following paths are considered system classes. System classes are visible to application classes.
// System classes cannot be replaced by classes from application JARs and can only be loaded by the system classloaderpublic static final ClassMatcher __dftSystemClasses = new ClassMatcher( "java.","javax.","org.xml.","org.w3c.");Server classes are not visible to any application. Jetty also uses package path names to identify Server classes. The configuration in WebAppContext is as follows:
// Loaded by the system classloader and invisible to web applicationspublic static final ClassMatcher __dftServerClasses = new ClassMatcher( "org.eclipse.jetty.");```We can set Server classes using the `WebAppContext.addServerClasses` or `WebAppContext.addServerClassMatcher` methods. Note that Server classes are invisible to all applications, but application classes under WEB-INF/lib can replace Server classes.
> Code location: jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebAppContext.java
```javapublic static void addServerClasses(Server server, String... pattern) { addClasses(__dftServerClasses, SERVER_SRV_CLASSES, server, pattern);}
public static void addSystemClasses(Server server, String... pattern) { addClasses(__dftSystemClasses, SERVER_SYS_CLASSES, server, pattern);}
public void addServerClassMatcher(ClassMatcher serverClasses) { _serverClasses.add(serverClasses.getPatterns());}
public void addSystemClassMatcher(ClassMatcher systemClasses) { _systemClasses.add(systemClasses.getPatterns());}```The constructor of WebAppClassLoader is as follows:```javapublic WebAppClassLoader(ClassLoader parent, Context context) throws IOException { // Specify parent class loader super(new URL[]{}, parent != null ? parent : (Thread.currentThread().getContextClassLoader() != null ? Thread.currentThread().getContextClassLoader() : (WebAppClassLoader.class.getClassLoader() != null ? WebAppClassLoader.class.getClassLoader() : ClassLoader.getSystemClassLoader()))); _parent = getParent(); _context = context; if (_parent == null) throw new IllegalArgumentException("no parent classloader!");
// File types that the class loader can load: jar or zip packages _extensions.add(".jar"); _extensions.add(".zip");}The constructor can explicitly specify a parent class loader. By default, it is null, meaning the current thread’s context classLoader is designated as the parent. If not specified by the user, this thread context classLoader will default to the previously mentioned System ClassLoader.
Now let’s look at the loadClass method.
@Overrideprotected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { ClassNotFoundException ex = null; Class<?> parentClass = null; // From parent class loader Class<?> webappClass = null; // From webapp class loader``` // First search from already loaded classes webappClass = findLoadedClass(name); if (webappClass != null) { return webappClass; }
// First try loading from current class loader (true here indicates checking if the class is a system class, if not, return the loaded class) webappClass = loadAsResource(name, true); if (webappClass != null) { return webappClass; }
// Then try loading from parent class loader try { parentClass = _parent.loadClass(name); // Check if loading server classes is allowed, or if the current class is not a server class if (Boolean.TRUE.equals(__loadServerClasses.get()) || !_context.isServerClass(parentClass)) { return parentClass; } } catch (ClassNotFoundException e) { ex = e; }
// Try loading from current class loader again (false here indicates not checking if the class is a system class) webappClass = loadAsResource(name, false); if (webappClass != null) { return webappClass; } throw ex == null ? new ClassNotFoundException(name) : ex; }}4.4.2 Tomcat Class Loader
Similar to the Jetty container, Tomcat also needs to comply with the three servlet specifications. The inheritance relationship of Tomcat’s class loaders is shown in Figure 4-6 below.
Figure 4-6 Inheritance Relationship of Tomcat Class Loaders
4.4.2.1 WebappClassLoader> Source: apache-tomcat-10.1.13-src/java/org/apache/catalina/loader/WebappLoader.java
public class WebappClassLoader extends WebappClassLoaderBase { public WebappClassLoader() { super(); } public WebappClassLoader(ClassLoader parent) { super(parent); }
//...}WebappClassLoader extends WebappClassLoaderBase, with the core class loading functionality primarily implemented in WebappClassLoaderBase. Looking directly at the code of WebappClassLoaderBase, it is an abstract class that inherits from URLClassLoader and overrides the loadClass method.
Source: apache-tomcat-10.1.13-src/java/org/apache/catalina/loader/WebappClassLoaderBase.java
First, let’s examine its properties and constructor:
// Whether to use the parent delegation modelprotected boolean delegate = false;
// Class loader for loading JavaSE classesprivate ClassLoader javaseClassLoader;
// Parent loader of the current class loaderprotected final ClassLoader parent;
protected WebappClassLoaderBase() { super(new URL[0]); // If no parent loader is specified during initialization, the parent defaults to the system class loader ClassLoader p = getParent(); if (p == null) { p = getSystemClassLoader(); } this.parent = p;
// Initialize javaseClassLoader as the platform class loader or extension class loader ClassLoader j = String.class.getClassLoader(); if (j == null) { j = getSystemClassLoader(); while (j.getParent() != null) { j = j.getParent(); } } this.javaseClassLoader = j;}The loadClass method is overridden as follows:
@Overridepublic Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class<?> clazz = findLoadedClass0(name); if (clazz != null) return clazz;``` // If not found in the web application's local class cache, search in the system class loader cache, // If found, it means AppClassLoader has already loaded this class before clazz = findLoadedClass(name); if (clazz != null) return clazz;
// Convert class names like java.lang.String to java/lang/String format String resourceName = binaryNameToPath(name, false); // Get the bootstrap class loader (BootstrapClassLoader) ClassLoader javaseLoader = getJavaseClassLoader(); boolean tryLoadingFromJavaseLoader; try { // The bootstrap class loader gets the resource URL based on the converted class name // If the URL is not null, it means the class to be loaded is found URL url = javaseLoader.getResource(resourceName); tryLoadingFromJavaseLoader = (url != null); } catch (Throwable t) { // ... }
// First, try loading from the extension class loader (ExtClassLoader) if (tryLoadingFromJavaseLoader) { return javaseLoader.loadClass(name); }
// delegate allows class loading to be delegated to the parent class loader boolean delegateLoad = delegate || filter(name, true); if (delegateLoad) { return Class.forName(name, false, parent); } // Load from the current web path clazz = findClass(name);
// If the class still hasn't been loaded after the above steps, // use the system class loader (also known as the application class loader) to load it if (!delegateLoad) { return Class.forName(name, false, parent); } } // Finally, if the class still hasn't been loaded, throw ClassNotFoundException throw new ClassNotFoundException(name);}4.2.2.3 JSP Class Loader
The JSP class loader also inherits from URLClassLoader and overrides loadClass. Let’s examine its source code.
Source: apache-tomcat-10.1.13-src/java/org/apache/jasper/servlet/JasperLoader.java```java public class JasperLoader extends URLClassLoader {
@Overridepublic synchronized Class<?> loadClass(final String name, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = null;
// Look up in JVM class cache clazz = findLoadedClass(name); if (clazz != null) { if (resolve) { resolveClass(clazz); } return clazz; }
// SecurityManager code omitted
// If class name doesn't start with org.apache.jsp package, use WebappClassLoader to load if( !name.startsWith(Constants.JSP_PACKAGE_NAME + '.') ) { clazz = getParent().loadClass(name); if( resolve ) { resolveClass(clazz); } return clazz; }
// For classes starting with org.apache.jsp package, call URLClassLoader's findClass method // to dynamically load class files, parse into Class objects, and return to caller return findClass(name);}}
From the source code, we can see that JSP class loading first attempts to load from the JVM class cache (classes loaded by Bootstrap and other class loaders). If it's not a JSP class, it loads from the web application class loader WebappClassLoader. If still not found, it loads from the specified URL path.
The initialization code for JasperLoader is as follows:
> Source: apache-tomcat-10.1.13-src/java/org/apache/jasper/JspCompilationContext.java
```javapublic ClassLoader getJspLoader() { if( jspLoader == null ) { jspLoader = new JasperLoader(new URL[] {baseUrl}, getClassLoader(), basePackageName, rctxt.getPermissionCollection()); } return jspLoader;}When initializing JasperLoader, the loading path and parent loader are specified.## 4.5 Thread Context Class Loader
In the previous sections, we focused on analyzing the implementation principles of the parent delegation model and arrived at a fundamental conclusion: child class loaders can use classes already loaded by parent class loaders, whereas parent class loaders cannot use classes loaded by child class loaders. This leads to situations where the parent delegation model cannot solve all class loader issues. For example, Java provides certain interfaces (Service Provider Interface, SPI) such as JDBC, JNDI, and JAXP. These interface classes are loaded by either the BootstrapClassLoader or PlatformClassLoader, but their implementations are typically provided by third parties and loaded by the AppClassLoader. The BootstrapClassLoader cannot load the implementation classes of these core interfaces because it only loads Java’s core libraries. It also cannot delegate to the AppClassLoader since it is the topmost class loader. In other words, the parent delegation model cannot resolve this issue. To address this problem, Java introduced the thread context class loader (ContextClassLoader).
The relevant content about the thread context class loader is found in the Thread class, as shown in the following code:
jdk11/src/java.base/share/classes/java/lang/Thread.java
public class Thread implements Runnable { // Other properties omitted... private ClassLoader contextClassLoader;
// Get the context class loader public ClassLoader getContextClassLoader() { if (contextClassLoader == null) return null; return contextClassLoader; }
// Set the context class loader public void setContextClassLoader(ClassLoader cl) { contextClassLoader = cl; }
// Create a thread instance private Thread(ThreadGroup g, Runnable target, String name, long stackSize, AccessControlContext acc, boolean inheritThreadLocals) { // The thread creating this thread instance Thread parent = currentThread();
g.addUnstarted();
this.group = g; this.daemon = parent.isDaemon(); this.priority = parent.getPriority();``` // Initialize to parent thread's context class loader if (security == null || isCCLOverridden(parent.getClass())) this.contextClassLoader = parent.getContextClassLoader(); else this.contextClassLoader = parent.contextClassLoader;
// Other code omitted....... }}From the source code, we can see that the thread context class loader is an attribute of the Thread class. It can cache the class loader used by the current thread, inherits the parent thread’s context class loader when the thread is created, and can be set to other values during thread execution.
In JDBC, DriverManager is used to manage different database drivers introduced in a project, such as MySQL drivers and Oracle drivers. In JDK 11, the DriverManager class is in the java.sql module, which is loaded by the PlatformClassLoader, while the MySQL driver classes in dependencies are loaded by the application class loader. Under the parent delegation model, DriverManager cannot access MySQL driver classes. Here, JDK uses the context class loader to bypass this restriction.
Let’s look at the DriverManager source code implementation:
jdk11/src/java.sql/share/classes/java/sql/DriverManager.java
public static Driver getDriver(String url) throws SQLException { // Load driver class ensureDriversInitialized();
for (DriverInfo aDriver : registeredDrivers) { try { if (aDriver.driver.acceptsURL(url)) { return (aDriver.driver); // Get driver } } catch(SQLException sqe) { // ignore } } throw new SQLException("No suitable driver", "08001");}From its name, ensureDriversInitialized ensures that driver classes are properly initialized, then iterates through registered drivers and returns the Driver object. Let’s first examine how the ensureDriversInitialized method obtains driver classes.
private static void ensureDriversInitialized() { if (driversInitialized) return;```java synchronized (lockForInitDrivers) { if (driversInitialized) return; String drivers; // Get driver class names from system environment variables try { return System.getProperty(JDBC_DRIVERS_PROPERTY); } catch (Exception ex) { drivers = null; } // Use ServiceLoader to read driver implementations from jar packages ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class); Iterator<Driver> driversIterator = loadedDrivers.iterator(); try { while (driversIterator.hasNext()) { driversIterator.next(); } } catch (Throwable t) { // Do nothing }
// Class loading if (drivers != null && !drivers.equals("")) { String[] driversList = drivers.split(":"); for (String aDriver : driversList) { try { // Attempt to load the class here. If SystemClassLoader fails, driver initialization fails Class.forName(aDriver, true, ClassLoader.getSystemClassLoader()); } catch (Exception ex) { // ... } } }
driversInitialized = true; }}The loading of driver classes mainly occurs in ServiceLoader.load(Driver.class). The implementation of the load method is as follows:
jdk11/src/java.base/share/classes/java/util/ServiceLoader.java
public static <S> ServiceLoader<S> load(Class<S> service) {ClassLoader cl = Thread.currentThread().getContextClassLoader();return new ServiceLoader<>(Reflection.getCallerClass(), service, cl);}From the source code, we can see that the current thread’s context class loader is used when loading classes.
4.6 Hot Loading and Unloading
During the class loading process, we know that the JVM first checks whether the class has already been loaded. If it has, it won’t look for the class in jar packages or paths but will use the cached class instead. The JVM determines whether two classes are the same based on two conditions: first, whether their fully qualified names are identical, and second, whether their class loader instances are the same. Therefore, to achieve hot loading of classes, different class loaders can be used to load the same class file. Using different class loader instances to load the same class file will result in an increasing number of class instances as loading occurs repeatedly. If metaspace/permanent generation is not cleaned up promptly, there is a risk of memory overflow.
However, the conditions for class unloading are very stringent. Generally, all three of the following conditions must be met simultaneously, and a full GC must be performed by the JVM before complete cleanup can occur. The three conditions for class unloading are as follows:
Figure 4-7 Conditions for Class Unloading
The timing of full GC is beyond our control, and consequently, so is class unloading. From the three conditions above, we can see that the JVM’s built-in class loaders cannot be reclaimed, meaning classes loaded by the JVM will not be unloaded. Only custom class loaders have the potential to be unloaded. Below is a specific requirement implemented using hot loading: an application loads a class script at runtime, and the script can be hot-updated. There is a script interface with computation execution functionality.
public interface Script { // Execute computation String run(String key);}The implementation class of the script is responsible for specific computation functionality.
public class ScriptImpl implements Script {
public ScriptImpl() { }
public String run(String key) { return key; }}Replacing the script implementation during JVM runtime enables script updates.
public class Main { public static void main(String[] args) throws Exception { ClassLoader appClassloader = Main.class.getClassLoader();
ScriptClassLoader scriptClassLoader1 = new ScriptClassLoader("resources", appClassloader); Class<?> scriptImpl1 = scriptClassLoader1.loadClass("ScriptImpl"); System.out.println(scriptImpl1.hashCode());```ScriptClassLoader scriptClassLoader2 = new ScriptClassLoader("resources", appClassloader); Class<?> scriptImpl2 = scriptClassLoader2.loadClass("ScriptImpl");
// The class objects are not identical assert scriptImpl1 != scriptImpl2; }}When loading the same class using different class loaders, the resulting class objects will be different. This allows for runtime updates to the implementation of the ScriptImpl class. The implementation of ScriptClassLoader is as follows:
public class ScriptClassLoader extends ClassLoader { private String classDir;
public ScriptClassLoader(String classDir,ClassLoader classLoader) { super(classLoader); this.classDir = classDir; }
@Override protected Class<?> findClass(String name) throws ClassNotFoundException { try { byte[] classDate = getClassByte(name); if (classDate == null) { return null; } return defineClass(name, classDate, 0, classDate.length); } catch (IOException e) { e.printStackTrace(); } return null; }```java private byte[] getClassByte(String className) throws IOException { InputStream in = null; ByteArrayOutputStream out = null; String path = classDir + File.separatorChar + className.replace('.', File.separatorChar) + ".class"; try { in = new FileInputStream(path); out = new ByteArrayOutputStream(); byte[] buffer = new byte[2048]; int len = 0; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } return out.toByteArray(); } catch (FileNotFoundException e) { e.printStackTrace(); } finally { in.close(); out.close(); } return null; }}
Setting debug breakpoints at the premain entry can be challenging. You may add a slight delay when entering the premain method.
