How Java ClassLoaders Work Internally

Java's class loading mechanism is implemented through ClassLoader, and its core workflow is divided into three stages: loading, linking and initialization. During the loading phase, ClassLoader dynamically reads the bytecode of the class and creates Class objects; links include verifying the correctness of the class, allocating memory to static variables, and parsing symbol references; initialization performs static code blocks and static variable assignments. Class loading adopts the parent delegation model, and prioritizes the parent class loader to find classes, and try Bootstrap, Extension, and Application ClassLoader in turn to ensure that the core class library is safe and avoids duplicate loading. Developers can customize ClassLoader, such as URLClassLoader for remote loading, WebApp ClassLoader implements application isolation, and OSGi supports modular dynamic loading. In addition, class unloading depends on the recycling of ClassLoader. If ClassLoader is referenced, it cannot release memory, which can easily lead to leakage. The life cycle needs to be managed reasonably to optimize resources. Mastering the ClassLoader principle helps troubleshoot problems, optimize structure and design plug-in systems.

Java's class loading mechanism is an important part of the JVM runtime, and ClassLoader is the core of this mechanism. Understanding how ClassLoaders works will help troubleshoot class loading problems, optimize program structure, and even help you better design a modular system.

Basic process of class loading

When a Java program runs, not all classes are loaded from the beginning. Instead, when the class is used for the first time, it is loaded into memory by the ClassLoader. This process is roughly divided into three stages:

• Loading : Find the binary bytecode file of the class (usually a .class file), read and create a Class object.
• Linking : includes three steps: verification, preparation and parsing. Verify to ensure the correctness of the class; prepare to allocate memory for static variables and set default values; parsing is to replace symbolic references with direct references.
• Initialization : Execute the class constructor <clinit></clinit> method, which is the static code block and static variable assignment operations we write.

Among these three steps, loading is done by ClassLoader, and the remaining two stages are controlled by the JVM.

Parent Delegation Model

ClassLoaders in Java adopts a mechanism called "parent delegation" to avoid duplicate loading of classes. Each ClassLoader has a parent class loader. When loading the class, it will first delegate to the parent class to load. Only when the parent class cannot be loaded will it try to load it by itself.

The standard ClassLoader hierarchy is as follows:

• Bootstrap ClassLoader : is responsible for loading the core classes (such as java.lang.Object ) that come with the JVM, usually located in rt.jar.
• Extension ClassLoader : Loads Java extension library, generally located in jre/lib/ext directory.
• Application ClassLoader (also called System ClassLoader): Loading the class under the application classpath, is the ClassLoader we deal with most often.

For example, when you call Class.forName("com.example.MyClass") , the default is that the Application ClassLoader initiates the loading request. It will first ask Extension, then ask Bootstrap. If none of them are found, then go to classpath to find it yourself.

The advantage of this mechanism is that it ensures the consistency and security of the class and prevents user-defined classes from overwriting the core class library.

Common ClassLoader implementation and usage

In addition to the standard ClassLoader mentioned above, Java also allows developers to customize ClassLoader to meet specific needs, such as loading classes from the network, hot deployment, plug-in systems, etc.

Several common ClassLoaders:

• URLClassLoader : It can load classes based on URLs (such as local files or remote HTTP addresses), suitable for dynamic loading of external JAR packages.
• Custom ClassLoader : Inheriting ClassLoader and rewriting findClass() or loadClass() methods can implement your own class loading logic.
• WebApp ClassLoader (commonly in Tomcat): Each web application has its own independent ClassLoader, which is used to isolate the class versions of different applications.
• OSGi ClassLoader : used in modular systems, supporting dynamic loading and unloading of classes.

If you are developing a plug-in system, you may need to customize a ClassLoader to load the plug-in's JAR file from the specified directory. For example:

 public class PluginClassLoader extends ClassLoader {
    private final File jarFile;

    public PluginClassLoader(File jarFile, ClassLoader parent) {
        super(parent);
        this.jarFile = jarFile;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] classBytes = readClassFromFile(name);
            return defineClass(name, classBytes, 0, classBytes.length);
        } catch (IOException e) {
            throw new ClassNotFoundException("Class " name " not found", e);
        }
    }

    private byte[] readClassFromFile(String name) throws IOException {
        // Actually read the bytecode of the class from the JAR...
    }
}

This way you can load the classes in the plug-in through this class loader.

Class Uninstallation and Memory Management

What many people don't know is that classes can be uninstalled, but this only happens when the corresponding ClassLoader is garbage collected. In other words, as long as your ClassLoader is still referenced, all classes it loads will not be recycled, which can easily cause memory leakage.

Therefore, when using a custom ClassLoader, you should pay attention to timely release resources, especially in frequent loading/unloading scenarios, such as hot updates or dynamic module loading.

A common practice is to place the ClassLoader in a weak reference container, or manually set it to null when it is no longer needed to allow GC to be recycled smoothly.

Basically that's it. ClassLoader is a relatively low-level but very practical part of Java. Mastering its principles and usage can help you write more flexible and robust applications.

The above is the detailed content of How Java ClassLoaders Work Internally. For more information, please follow other related articles on the PHP Chinese website!