This is the fifth day of my participation in the More text Challenge. For details, see more text Challenge
If the interviewer asks you, what are the steps in the class loading process?
Blah, blah, blah… (Load, verify, prepare, parse, initialize)
Seeing this young man’s face surprised, face flushed, involuntarily asked parents to delegate model to say it; Meet not fully prepared, instant meng.
Let’s take a look at this interesting virtual machine class loading mechanism.
When we talk about parent delegates, we must first talk about classloaders in Java.
Class loaders in Java
Bootstrap ClassLoader
The Bootstrap ClassLoader is used to start class loading. By default, it loads many classes in the JAR in the JDK lib directory.
This path can be specified using the -xbootclasspath parameter.
Extension ClassLoader (Extension ClassLoader)
The Extension ClassLoader loads classes in the JAR directory in the JDK, lib, ext, etc.
This path can be changed using the java.ext.dirs system variable.
Application ClassLoader
The Application ClassLoader is responsible for loading the classes written by the developer.
User ClassLoader
Custom class loaders. When there are special cases that cannot be solved by the class loaders mentioned above, or when there are special requirements, the class loading logic can be implemented by itself.
The relationship is shown in the figure:
What is the parent delegation model?
With class loaders out of the way, let’s talk about the parent delegate model.
It was introduced during JDK1.2, has since been recommended to developers, and is now the most commonly used class loader implementation.
The entire process of parent delegation is divided into the following steps:
-
If the user just wrote the Test class and wants to load it, it will first be sent to the application class loader, AppCloassLoader.
-
Instead of loading the Test class directly, the AppClassLoader will delegate to the parent classloader, which is the ExtClassLoader.
-
The ExtClassLoader also does not load the Test class directly. Instead, it continues to delegate to the parent class loader, which is BootstrapClassLoader.
-
The BootstrapClassLoader will search in the JDK /lib directory to see if there is a Test class written by the user, and it will not exist in the JDK. So at this point we will give the subclass loader a feedback.
-
ExtClassLoader received the parent class loader sent feedback, know that the parent class loader did not find the corresponding class, dad can not rely on, can only be their own to load, the obvious result, their own not, no way, can only give the following subclass loader.
-
When AppClassLoader receives the feedback from the parent class loader, it immediately realizes that although the father is the father, he can’t be in charge of his son’s private affairs. So at this time, AppClassLoader tries to load the class itself.
-
As a result, so successful, walk a big circle, around or their own work.
It’s not that complicated, SO I’m not going to draw it, but if you want to see it, you can look it up again on the Internet, and I remember a big guy who drew it very vividly.
Why use the parent delegate model?
Using the parent delegate model has the great advantage of avoiding the problem of overwriting the original class.
For example, if the user writes an Object class and puts it in the program to load it.
When there is no parent delegate mechanism, duplicate Object classes can occur, which can cause a lot of trouble for developers who need to memorize all the classes in the JDK to avoid writing duplicate classes.
When you have a parent delegate mechanism, the whole thing is different, every time you load a class, you follow the parent delegate mechanism, you ask the parent if it’s ok to load it, and if it’s ok, you don’t have to load it again, and that makes things easier. The way I go, the boy can’t go.
How to break the parent delegation model?
This question, in fact, is the most in-depth question in the parent delegation model, at least in the middle and senior engineer interview, which is the next topic.
Here I will also briefly say, the most common and people often say there are two, respectively:
- In a custom class loader, override the loadClass method.
Why is that? Because if you look at the source code for the ClassLoader class, you’ll see that the core of the parent delegate is in this method; If you override this method, you automatically break the parent delegate mechanism.
- Use the thread context classloader
Because the parent delegate mechanism does not support the Service Provider Interface (SPI), the thread context classloader is introduced, which can break through the hierarchy of the parent delegate model and use the class loader to complete the class loading in reverse.
There is no way to do this at present. All the classes involved in SPI are using this method to complete class loading, including JNDI, JDBC, JAXB, etc.
There is another case where the parent delegate model can be broken, and that is OSGI. This is explained in the book “Understanding the Java Virtual Machine”, probably by the author who is familiar with OSGI and has a book on OSGI from the introduction.
In many application environments, OSGI is used as the key to the implementation of modular hot deployment, so, in this case, OSGI must do something about the class loading process.
Because this is not often encountered, or you go to check it, I will not repeat it here.