A brief talk on java class loading mechanism

I have a Java background, but I am ashamed to say it, but I don't know the underlying level of Java very well, such as the class loading mechanism that will fade away in a while.

Have you ever thought about how this program works when you run a java program? Maybe some friends will say, first compile it into bytecode, and then load it into memory to run. Yes, this is indeed the case, the new question is here again, how did it load it? This will involve the java class loading mechanism.

Understand the class loading mechanism, you can dynamically load the corresponding class during the running of the program, thereby improving the flexibility and adaptability of the program.

A program HelloWorld.java, it needs to run, it is not simply done by loading its bytecode into memory, it needs the support of jdk and jre. This is like building a building. Without the foundation below, this building cannot be completed. So before loading HelloWorld.class, you must load jdk and jre into memory. So how to add it? The so-called classloader is used here. Having said that, I don’t know if you have noticed that we need to load jdk, jre, HelloWorld.class, can we use a loader to load these three? Answer: No. Because the levels of these three are different, different loaders need to be used. First of all, jdk is the core library of java, which means it is the bottom layer, so when loading it, you need a loader that can deal with the bottom layer. Here jvm provides the bootstrap class loader (it is written by c, other The loaders are all written in java). Secondly, jre is an extension class library of jdk, and jvm provides an extension class loader. Finally, JVM provides an application class loader, specifically used to load user-defined classes, such as HelloWorld.

The entire loading sequence is the same as described in the preface, bootstrap class loader, extension class loader, application class loader. First, the bootstrap class loader loads other classloaders when it comes up. With these classloaders, the subsequent load work is carried out in order. Here, each classloader holds a reference to the upper classloader, so the relationship between classloaders is not an inheritance relationship, but an association relationship. In the loading process, the classloader first finds whether the upper layer of loader has been loaded, if it has been loaded, it will not load again. This ensures safety. For example, the String written by yourself will never have a chance to be loaded because the upper layer has been loaded. In addition, each classloader is only responsible for the classes within its own jurisdiction. In addition, there are other loaders, which are not listed in detail here.

Here is an example from others:

public class HelloWorld { 
        public static void main(String[] args) { 
                HelloWorld hello = new HelloWorld(); 
                Class c = hello.getClass(); 
                ClassLoader loader = c.getClassLoader(); 
                System.out.println(loader); 
                System.out.println(loader.getParent()); 
                System.out.println(loader.getParent().getParent()); 
        } 
}
 
Print result:
sun.misc.Launcher$AppClassLoader@19821f 
sun.misc.Launcher$ExtClassLoader@addbf1 
null 

Process finished with exit code 0
 
It can be seen from the above results that the upper Loader of ExtClassLoader is not obtained because the Bootstrap Loader (startup class loader) is implemented in C language, and there is no definite way to return to the upper Loader, so null is returned. .

Guess you like

Origin blog.csdn.net/hongyinanhai00/article/details/48732621