Difference Between Thread’s Context Class Loader and Normal Class Loader – Thread’的上下文类加载器和普通类加载器之间的区别

最后修改: 2022年 5月 31日

1. Overview


Java uses different types of class loaders to load resources during program execution. In this tutorial, we’ll explore the difference in the behavior of current and thread class loaders in Java.

Java 使用不同类型的类加载器来在程序执行期间加载资源。在本教程中,我们将探讨Java中的当前类加载器和线程类加载器的行为差异。

2. What Does a Class Loader Do?


Java class loaders locate and load the classes required for application execution. If the requested class is dependent on any other resources, they are loaded as well.


We need appropriate class loaders for loading different types of classes whenever required by Java programs.


3. Relationship Between Class Loaders


Java class loaders follow a hierarchical relationship.


Each request to find or load a class is delegated to the respective parent class loader. If all the ancestor class loaders are unable to find a class, then the current class loader tries to locate it. Here, “current class”  implies the class of the currently executing method.

每个寻找或加载一个类的请求都被委托给相应的父类加载器。如果所有的祖先类加载器都无法找到一个类,那么当前的类加载器就会尝试找到它。这里,”当前类 “指的是当前执行的方法的类。

This relationship between class loaders helps in maintaining the uniqueness of resources in an application. Additionally, if a class has already been loaded by a parent class loader, the child class loader doesn’t need to reload it.


4. Default Class Loaders


Class loaders load classes and resources present on their respective classpath:


  • System or application class loaders load classes from the application classpath
  • Extension class loaders search on the Extension classpath (JRE/lib/ext)
  • Bootstrap class loader looks on the Bootstrap classpath (JRE/lib/rt.jar)

A Bootstrap or Primordial class loader is the parent of all class loaders. It loads the Java runtime – the classes required to run the JVM itself.

Bootstrap 或 Primordial 类加载器是所有类加载器的父类。它加载Java运行时–运行JVM本身所需的类。

Current class loaders search for resources in a linear, hierarchical fashion. If a class loader can’t locate a class, it throws java.lang.ClassNotFoundException to the corresponding child class loader. The child class loader then tries to search for the class.


For scenarios where required resources aren’t found on classpaths of any of the class loaders in the hierarchy, we get error messages related to java.lang.ClassNotFoundException as the end result.


We can customize the default class loading behavior as well. We can explicitly specify the class loader while loading a class dynamically.


However, we should note that if we load the same class from different types of class loaders, these will be seen as different resources by the JVM.


5. Context Class Loaders


Apart from the default class loaders, J2SE also introduced context class loaders.

除了默认的类加载器之外,J2SE 还引入了context 类加载器

Each thread in Java has an associated context class loader.


We can access/modify the context class loader for a thread using the getContextClassLoader() and setContextClassLoader() methods of the Thread class.


The context class loader is set at the time of the creation of a thread. If not set explicitly, it defaults to the context class loader of the parent thread.

上下文类加载器在创建线程时被设置。如果没有明确设置,它 默认为父线程的上下文类加载器

Context class loaders also follow the hierarchy model. The root class loader, in this case, is the context class loader of the primordial thread. A primordial thread is the initial thread created by the operating system.


As the application starts executing, other threads may get created. The context class loader of a primordial thread is initially set to the class loader that loads the application, i.e., the system class loader.


Suppose we don’t update the context class loader for any thread at any level of the hierarchy. As a result, we can say that by default, the context class loader for a thread is the same as the system class loader. For such scenarios, if we perform Thread.currentThread().getContextClassLoader() and getClass().getClassLoader() operations, both will return the same objects.


5.1. Handle Issues With Delegation


Context class loaders are significant when required resources aren’t present on the classpath of the default Java class loaders. Therefore, we can use context class loaders to diverge from the traditional linear delegation model.


In the hierarchical model of class loaders, resources loaded by parent class loaders are visible to the child class loaders, but not vice versa. In some scenarios, parent class loaders might need to access classes present on the classpath of child class loaders.


Context class loaders are a useful tool to make this happen. We can set the context class loader to the desired value when accessing required resources. Hence, in the above case, we can use the child thread’s context class loader and can locate the resources present at the child class loader level.


5.2. Multi-Module Environment


While setting the context class loader property, we’re basically switching the context for loading resources. Instead of searching at the current classpath, we fetch a new class loader pointing to a different classpath. This is particularly helpful if we want to load resources from a third-party module or if we are working in an environment with different class namespaces.


However, we should exercise caution here and reset the context class loader property back to the original class loader to avoid any future discrepancies.


6. Conclusion


In this article, we’ve analyzed the significance of using context class loaders to load resources not accessible via normal class loaders. We saw that we could also choose to temporarily update the context class loader for a given thread for loading required classes.


It is essential to understand the context in which the current method is working. We can have resources with the same name existing on different classpaths. Hence, while loading resources from multiple class loaders, we should exercise caution.