Understanding Java Classloader Hierarchy

The core of the Java class loading mechanism is the hierarchy of the class loader and the parent delegation model. 1. Bootstrap ClassLoader is responsible for loading JVM core classes; 2. Extension ClassLoader loads Java extension class library; 3. Application ClassLoader loads classes on the application classpath. Class loading follows the parent delegation model, that is, class loading requests will be delegated to the parent class loader first, and subclasses will only attempt to load when the parent class cannot be loaded, so as to avoid duplicate loading of classes and ensure security. Custom class loaders can be used in hot deployment, modular loading and other scenarios. They usually inherit ClassLoader and override the findClass() method. If you need to break the parent delegation, you can override loadClass(). In addition, class loaders implement class isolation in web containers, and thread context class loaders are used for specific scenarios such as JDBC driver loading. Understanding the class loading mechanism helps troubleshoot class conflicts, optimize plug-in systems and hot deployment solutions.

Java's class loading mechanism is a very core part of the JVM, and the hierarchy of the class loader (ClassLoader) is the key. Understanding the hierarchical relationship of ClassLoader can help troubleshoot class loading problems, avoid class conflicts, and can even come in handy when developing plug-in systems or hot deployment solutions.

The three major roles of Java ClassLoader

There is not only one class loader in Java, but three main built-in class loaders that form a parent-child hierarchy:

• Bootstrap ClassLoader : is responsible for loading the core classes that come with the JVM, such as java.lang.Object , which are usually located in rt.jar . It is implemented by C, not a Java class.
• Extension ClassLoader : The extension class library responsible for loading Java, which is generally located in jre/lib/ext directory or the location specified by java.ext.dirs .
• Application ClassLoader (also known as System ClassLoader) : is responsible for loading classes on the application classpath and is the classloader we deal with most frequently.

A "tree-like" structure is formed between these three class loaders. Bootstrap is the root node, Extension is its child node, and Application is also the child node of Extension.

How does the parent delegation model work?

Java class loading follows a mechanism called the "Parent Delegation Model". Simply put, when a class loader receives a request to load a class, it does not load it first, but delegates the request to its parent class loader to complete it until the top-level Bootstrap ClassLoader.

The current class loader attempts to load only when the parent class loader cannot complete the loading task (such as not finding the corresponding class).

There are two main benefits of this mechanism:

• Avoid duplicate class loading: The same class will only be loaded once and will be done by as advanced class loaders as possible.
• Ensure the security of the class: prevent users from impersonating classes in the core class library. For example, you wrote a java.lang.String , but because of the existence of parent delegation, the JVM will prioritize the use of Bootstrap loaded version to avoid security risks.

For example: When you use new String() in your code, the JVM will load java.lang.String through the Application ClassLoader, but it will first hand over the task to its parent class Extension ClassLoader, and then hand over it to the Bootstrap ClassLoader. Finally, Bootstrap successfully loaded this class from rt.jar, and the whole process ended.

Common uses and precautions for custom class loaders

Sometimes we need to customize ClassLoader, such as implementing hot deployment, modular loading, encrypted class files, etc. Custom class loaders generally inherit java.lang.ClassLoader and override findClass() method.

It should be noted that if you want to follow the parent delegation model, don’t rewrite loadClass() method casually; if you want to break this model (such as OSGi or some hot update frameworks), you can implement your own loading logic by rewriting loadClass() .

Several key points:

• If you want to implement class isolation (such as different modules load their respective classes without interfering with each other), you need to design the relationship between class loaders.
• In a web container (such as Tomcat), each web application has its own class loader, which can avoid class conflicts between different applications.
• Use the Thread Context ClassLoader to bypass the default class loader chain in some scenarios, such as the JDBC driver will be used when loading.

Let's summarize

The hierarchy of class loaders and parent delegation mechanism are one of the important foundations of the Java platform. Although we do not need to operate ClassLoader directly, understanding this mechanism can help us locate problems faster when encountering problems such as class loading exceptions and class conflicts. At the same time, in some advanced application scenarios, rational use of class loading mechanism can also bring flexibility and scalability.

Basically all is it, not complicated but it is easy to ignore details.

The above is the detailed content of Understanding Java Classloader Hierarchy. For more information, please follow other related articles on the PHP Chinese website!