Java classloader mechanism usage code analysis

For java development, the mechanism of classloader must be familiar with the basic knowledge. This paper makes a brief summary of the mechanism of Java classloader. Because different JVMs have different implementations, the content described in this article is limited to hotspot JVM

This article will discuss and summarize from four aspects: the default classloader provided by JDK, the parental delegation model, how to customize classloader and the scenario of breaking the parental delegation mechanism in Java.

JDK default classloader

The JDK provides the following classloaders by default

Bootstrp loader

Bootstrp loader is written in C + + language. It is initialized after the Java virtual machine is started. It is mainly responsible for loading% Java_ Home% / JRE / lib, the path specified by the - xbootclasspath parameter and% Java_ Classes in home% / JRE / classes.

ExtClassLoader

Boottrp loader loads extclassloader and sets the parent loader of extclassloader to boottrp loader Extclassloader is written in Java, specifically sun misc. Launcher $extclassloader, extclassloader mainly loads% Java_ Home% / JRE / lib / ext, all classes directories under this path and Java Class libraries in the path specified by the ext.dirs system variable.

AppClassLoader

After boottrp loader loads extclassloader, it will load appclassloader and specify the parent loader of appclassloader as extclassloader. Appclassloader is also written in Java, and its implementation class is sun misc. Launcher $appclassloader. In addition, we know that there is a getsystemclassloader method in classloader, which returns appclassloader Appclassloader is mainly responsible for loading the classes or jar documents at the location specified by the classpath. It is also the default class loader of Java programs.

Parental trust model

Classloader in Java adopts the two parent delegation mechanism. When using the two parent delegation mechanism to load classes, the following steps are adopted:

The current classloader first queries whether this class has been loaded from its loaded class. If it has been loaded, it directly returns the originally loaded class.

Each class loader has its own load cache. When a class is loaded, it will be put into the cache and can be returned directly when it is loaded next time.

When the loaded class is not found in the current classloader cache, the parent class loader is entrusted to load. The parent class loader adopts the same strategy. First, check its own cache, and then entrust the parent class of the parent class to load until boottrp classloader

When all parent class loaders are not loaded, the current class loader loads them and puts them into its own cache so that they can be returned directly when there is a load request next time.

At this point, you may wonder, why does Java adopt such a delegation mechanism? To understand this problem, we introduce another concept of classloader "namespace", which means that to determine a class, the fully qualified name of the class and the classloader loading this class are required to determine it together. That is, even if the fully qualified names of the two classes are the same, because different classloaders load this class, it is a different class in the JVM. Once you understand the namespace, let's look at the delegate model. After adopting the delegation model, the interaction capabilities of different classloaders are increased. For example, as mentioned above, the class libraries provided by our JDK students, such as HashMap, LinkedList, etc. after these classes are loaded by the boottrp class loader, no matter how many class loaders there are in your program, these classes can be shared, This avoids confusion caused by different class loaders loading different classes with the same name.

How to customize classloader

In addition to the default classloader mentioned above, Java also allows applications to customize the classloader. To customize the classloader, we need to inherit Java Lang. classloader. Next, let's take a look at several important methods we need to pay attention to when customizing classloader:

1. Loadclass method

loadClass method declare

The above is the prototype declaration of the loadclass method. The implementation of the parent delegation mechanism mentioned above is actually implemented in this method. Let's take a look at the code of this method to see how it implements parental delegation.

loadClass method implement

From the above, we can see that the loadclass method calls the loadclass (name, false) method. Next, let's look at the implementation of another loadclass method.

Class loadClass(String name,boolean resolve)

I annotated the above code, and you can clearly see how the parent delegation mechanism of loadclass works. Here, we need to pay attention to public class Loadclass (string name) throws classnotfoundexception is not marked as final, which means that we can override this method, that is, the two parent delegation mechanism can be broken. In addition, it is noted that there is a findclass method. Next, let's talk about the end of this method.

2.findClass

Let's look at Java From the source code of lang. classloader, we found that the implementation of findclass is as follows:

We can see that the default implementation of this method is to throw exceptions directly. In fact, this method is left to our application to override. Then the specific implementation depends on your implementation logic. You can read from the disk or get the byte stream of the class file from the network. After obtaining the class binary, you can hand it over to defineclass for further loading. Defineclass is described below. OK, through the above analysis, we can draw the following conclusions:

When writing our own classloader, if we want to follow the two parent delegation mechanism, we only need to override findclass

3.defineClass

Let's first look at the source code of defineclass:

defineClass

From the above code, we can see that this method is defined as final, which means that this method cannot be overridden. In fact, this is also the only entry left by the JVM. Through this unique entry, the JVM ensures that the class file must comply with the class definition specified in the Java virtual machine specification. This method will finally call the native method to load the real class.

OK, through the above description, let's consider the following question:

Suppose we write a Java Lang. string, can we replace the class calling JDK itself?

The answer is No. We can't do it. Why? I think many online explanations say that the parental entrustment mechanism to solve this problem is not very accurate. Because the parent delegation mechanism can be broken, you can write a classloader to load your own Java Lang. string class, but you will find that it will not load successfully, specifically because it is aimed at Java* The implementation of the JVM has guaranteed that the first class must be loaded by bootstrp.

Scenarios that do not follow the "two parent delegation mechanism"

As mentioned above, the two parent delegation mechanism is mainly used to realize the interaction of classes loaded between different classloaders. Classes shared by everyone are loaded by the parent loader, but there are also cases in Java where classes loaded by the parent loader need to use classes loaded by the child loader. Let's talk about the occurrence of this situation.

There is a SPI (service provider interface) standard in Java, which uses SPI libraries, such as JDBC and JNDI. We all know that JDBC needs a driver provided by a third party, and the jar package of the driver is placed in the classpath of our application, and the API of JDBC itself is a part of the JDK, which has been loaded by boottrp, How to load the implementation classes provided by third-party manufacturers? Java introduces the concept of thread context class loading. The thread class loader inherits from the parent thread by default. If it is not specified, it is the system class loader by default. In this way, when a third-party driver is loaded, it can be loaded through the thread context class loader.

In addition, in order to implement a more flexible class loader, OSGi and some Java app servers also break the two parent delegation mechanism.

summary

The above is all about the usage code analysis of Java classloader mechanism in this article. I hope it will be helpful to you. Interested friends can continue to refer to other related topics on this site. If there are deficiencies, please leave a message to point out. Thank you for your support!