Stop memorizing Java class loading

As a programmer, we can’t get around the JVM when we interview, which is our eternal pain. Don’t you feel like you have to recit it every time you go to an interview, or you’re going to get fucked.

So the question is, why do you memorize every interview? ‘ ‘why back over broken time to forget? In addition to the memory is not deep, there is an important reason is not understand, do not understand things, of course, remember soon.

So from the beginning of this article, we will start to learn the JVM, try to understand memory, the knowledge points together. Although this piece of knowledge is very boring, very boring, but I try to write simple, interesting point, we refueled together, ok?

Class loading mechanism

1.1 Complete Process (Simple version)

From the figure above, we can see that a simple Java program execution flow is as follows:

1. We write Java code locally

2. The compiler helps us to automatically compile the.class file (you can also manually compile the file through the javac command, because idea does it for us, in fact, the bottom layer still calls the javac command).

3. Next, deploy to a Web container and run it (you can also run it using the java-jar command)

The process feels simple enough to convert Java source files into Java-aware.class files and run them as a package.

1.2 Complete Process (Complex Version)

In fact, the entire life cycle of a class from step 2 (compile to a.class file) to step 3 (run) is not easy to describe. It includes complex and complete processes :(is not cheated, take a look at the picture below, very complex, dizzy 🤣)

The Loading phase is simple. When a program reaches the required class, the JVM loads it into memory through the class loader. Next, let’s take a look at what a class loader is and then walk through the entire class loading process in detail. (Come back later)

Class loaders

The Java Virtual Machine design team implemented the loading action outside of the Java virtual machine so that the program could decide when to fetch the required classes. The code that does this is called a classloader.

Simply put, the code that does the loading is called a classloader, and it is up to the application to decide.

Class loaders fall into three categories:

1. Bootstrap ClassLoaderIt is responsible for loading core libraries in the JDK installation directory (such as classes in the /lib directory) that the JVM runtime itself needs.
2. Extension ClassLoaderIt is responsible for loading extension libraries in the JDK installation directory (such as /lib/ext).
3. Application ClassLoaderResponsible for loading user-developed Java classes.

The above three types of loaders are intended for different class loaders, that is, a class can have only one class loader to load it.

4. Break the parental delegation model

We need to know that the parent delegate mechanism is not a mandatory constraint model, just the implementation of the class loader that Java designers recommend to us.

For example, Tomcat doesn’t implement the parent delegate model. Let’s think about it. Why doesn’t it implement the parent delegate model? (Moves his head)

Tomcat is a Web container that needs to address the issue of version isolation. That is, a Web container may need to deploy multiple applications, and different applications may rely on different versions of the same third-party class library. It is not necessary to have only one copy of the same class library on the same server. Therefore, it is necessary to ensure that the class libraries of each application are independent and isolated from each other.