The Java ClassLoader hierarchy consists of Bootstrap, Extension and Application ClassLoader. It adopts a delegate-first model to ensure the consistency and security of core classes. Class loading problems are common in classpath errors or class loader isolation. When troubleshooting, you need to check dependencies, logs and use -verbose:class parameters; custom ClassLoader needs to inherit and override findClass() to avoid duplicate loading and pay attention to the hot replacement mechanism.

Java's class loading mechanism is a very basic but easily overlooked part of the JVM. Many people do not directly deal with ClassLoader when writing code, but in actual development, such as using frameworks, containers, hot deployment and other functions, the behavior of ClassLoader often directly affects the operation of the program. Understanding its hierarchy and delegate model can help you better troubleshoot class loading issues.

What is the Java ClassLoader level?

Java's class loader does not have only one, but a layer of nested structures. The JVM provides three main class loaders by default:

• Bootstrap ClassLoader : Responsible for loading JDK core classes (such as java.lang.* ), which are usually implemented in C.
• Extension ClassLoader : Responsible for loading the extended class library ( jre/lib/ext or jar package under the specified path).
• Application ClassLoader (also called System ClassLoader): Responsible for loading classes in the user classpath.

These three class loaders form a parent-child structure, and each child loader has a parent loader. You can check which loader the current class is loaded by by calling getClass().getClassLoader() .

How does the class loaded delegate model work?

Java's class loading adopts a "delegate-first" model. That is to say, when a class loader receives a request to load a class, it will not load it immediately, but will first hand over the request to its parent class loader for processing. Only when the parent class loader cannot load this class, it will be attempted to load it by itself.

For example:

1. Your application class com.example.MyClass is loaded by the Application ClassLoader request;
2. It will first delegate to the Extension ClassLoader;
3. The Extension ClassLoader will be entrusted to the Bootstrap ClassLoader;
4. If neither Bootstrap nor Extension can find this class, the Application ClassLoader will actually go to classpath to find it.

This design is to ensure the consistency and security of core classes, and to avoid multiple class loaders repeatedly loading the same class, causing conflicts or waste of resources.

Why do NoClassDefFoundError or ClassNotFoundException sometimes appear?

Although these two exceptions look similar, the reasons behind them may be completely different.

Analysis of common causes

• ClassNotFoundException : Usually when you call Class.forName() or ClassLoader.loadClass() manually, the wrong class name is passed in, or the class does not exist in the classpath.
• NoClassDefFoundError : indicates that the class exists during the compilation period, but cannot be found at runtime. This is usually caused by errors in the static initialization block, or inconsistent class visibility among different class loaders.

For example, you have two modules A and B, A is loaded into a custom class loader, and B is loaded by the system class loader. If B tries to reference a class in A, this error will be caused because the class loader is invisible.

Solutions

• Check that the dependency is correctly packaged and placed in the correct classpath;
• Check whether there are any prompts for class loading failures in the log (some frameworks will print the class loading process at startup);
• Run the program with -verbose:class parameter and you can see the specific path and loader of the class loading;
• For web applications or plug-in systems, pay attention to whether the class loaders used by different modules are isolated.

What are the precautions for custom ClassLoader?

In some scenarios, such as hot deployment, encrypted class files, remote loading, etc., we may need to customize ClassLoader. Several key points need to be paid attention to at this time:

• Inheriting ClassLoader and rewriting findClass() method is the most recommended way;
• Don't override loadClass() easily unless you know clearly that you want to break the default delegate model;
• Ensure the uniqueness of class loading and avoid repeated loading of the same class by different class loaders;
• If you want to implement hot replacement, remember to uninstall the old class loader and create a new instance.

If you have multiple ClassLoaders in your application working at the same time, be sure to be clear about their relationship and loading order, otherwise it is easy to have problems such as "classes are found but methods are not found", "class conflicts" and other problems.

Basically that's it. Understanding the hierarchy and delegate model of ClassLoader is very helpful in solving class loading problems. Although I don’t know how to operate it directly, this knowledge can come in handy once I encounter problems.

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