The Java class loading mechanism is the core of the runtime, and understanding it helps to troubleshoot class conflicts, class failure, and other problems. Its basic process is divided into three stages: loading, linking (verification, preparation, parsing) and initialization, and is loaded on demand using Lazy Loading. Class loaders include Bootstrap ClassLoader, Extension ClassLoader, Application ClassLoader and custom class loaders, and use the parent delegation model to ensure uniqueness and security. Frequently asked questions include ClassNotFoundException, NoClassDefFoundError, class duplicate loading, resource leakage, etc. Recommendations for use include viewing the class loading path, enabling -verbose:class parameters, and paying attention to the loading order of container classes. Mastering its principles can improve the efficiency of problem investigation.

Java's class loading mechanism is one of the core parts of the Java language runtime. Understanding it can help you better troubleshoot problems, such as class conflicts, class failure, duplicate loading and other problems. Its mechanism is not complicated, but it has many details and is easy to get stuck in actual development.

This article will explain the class loading mechanism from several common perspectives, including its basic process, the type of class loader, and some areas where problems are prone to problems.

Basic process of class loading

When a Java program is running, it does not load all classes into memory at once, but instead "load on demand", which is the so-called Lazy Loading. The process of class loading can be divided into three main stages:

• Loading : Find and load the binary data of the class (usually a .class file) and generate a Class object.
• Linking :
  • Verification : Ensure that the bytecode of the class is legal and does not destroy the JVM.
  • Preparation : Allocate memory for static variables of the class and set the default initial value.
  • Resolution : Convert symbolic references of classes, methods and fields into direct references.
• Initialization : Execute static initialization code of the class (such as static code blocks and static variable assignments).

This process is done automatically and developers don't usually need intervention, but understanding it helps understand when the class is actually initialized.

Common class loaders

Java's class loader adopts the "parent delegation model", which is a hierarchy, aiming to ensure the uniqueness and security of the class. Common class loaders are:

• Bootstrap ClassLoader : Responsible for loading JVM core classes, such as the class in rt.jar , which is implemented in C and cannot be obtained by Java code.
• Extension ClassLoader : Responsible for loading classes in jre/lib/ext directory, or the location specified by java.ext.dirs .
• Application ClassLoader (also called System ClassLoader): is responsible for loading classes under the application classpath, which is the one we deal with the most frequently.
• Custom class loaders : Some frameworks (such as Tomcat, OSGi) will implement class loaders themselves to isolate classes from different modules.

When a class loader receives a request to load a class, it will first delegate to the parent class loader to process it. Only when the parent class loader cannot load it will try to load it itself.

Frequently Asked Questions and Precautions

In actual development, the class loading mechanism has many problems, the most common ones include:

• ClassNotFoundException / NoClassDefFoundError
  The former is that the specified class cannot be found at runtime, while the latter is that the class exists at compile time but cannot be found at runtime. This is usually because the classpath is not configured correctly, or there is a problem with the class loader level.

• Class duplicate loading
  If multiple class loaders are used, for example, each application in a web application has its own class loader, the same class may be loaded by multiple loaders, resulting in incompatible classes. For example, two class loaders each load different versions of the same class, and they are treated as two different classes in the JVM.

• Resource leakage
  Custom class loaders may cause memory leaks if resources are not released correctly. For example, when hot deployment or dynamically loading plugins, if the old class loader is not recycled, it may always occupy memory.

Recommendations for use

If you are just a normal business development, you may not need to write a class loader yourself, but understanding it can help you better locate problems. Here are some practical suggestions:

• To see where the class is loaded, you can use ClassLoader.getSystemClassLoader() or use Class.getResource() to view the classpath.
• When encountering a class conflict, you can use -verbose:class parameter to start the JVM to view the class loading log.
• If you are using a container like Tomcat, please note that it has its own class loading structure. For example, web applications preferentially load classes in their own directory rather than shared lib directories.

The class loading mechanism itself is not complicated, but in actual projects, it is easy to cause various problems due to problems such as classpaths and class loader structure. Understanding the basic principles and common problems can make you more efficient when troubleshooting problems.

Basically that's it.

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