Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the three-time destruction of the parental delegation model of Java". In the daily operation, I believe that many people have doubts about what is the three-time destruction of the parental delegation model of Java. The editor consulted all kinds of materials and sorted out a simple and useful method of operation. I hope it will be helpful to answer the doubts of "what is the three-time destruction of the parental delegation model of Java"! Next, please follow the editor to study!

Class loading

The code we usually write is saved in a .java file, which is compiled to generate a .class file, which stores bytecode, and if we want to use our code, it must be loaded into JVM.

Of course, the source that loads into JVM to generate class objects doesn't have to be a .class file, it can also come from a network, and so on, as long as it conforms to the JVM specification.

The steps of class loading are mainly divided into: loading, linking, initialization.

Load

It's all about finding the byte stream, loading it into JVM, and generating class objects. This is the stage when the classloader comes in handy, which we'll talk about in more detail later.

Link

This phase is to integrate the generated class objects into the JVM, which goes through the following three steps:

Validation is to verify that the loaded class meets the constraints of JVM, that is, to determine compliance.

Preparation is to request memory space for loading static variables of the class and give the initial value, for example, the int type, where the initial value is 0.

Parsing is to parse the symbolic reference into an actual reference, for example, if there is a XX class referenced in the Yes class, then the Yes class must not know the address of the XX class in memory at the beginning, so first get a symbolic reference instead, pretend to know, and then find the real address of the XX class when the class loads the parsing, and make an actual reference.

This is what parsing is about. Also, although parsing is included in the linking phase, the JVM specification does not require parsing to be completed during the linking process.

Initialization

This phase is to assign a value to the constant field, and then execute the static code block, wrapping a bunch of static code block methods to be executed as clinit methods, which are locked, and JVM ensures that the clinit method will only be executed once.

So an internal static class can be used to implement the singleton design pattern with delayed initialization while ensuring thread safety.

After this phase is over, the class loading process is ok and ready for use. Let's draw a diagram to summarize it:

Parental delegation model

In the loading phase, you need to use a class loader to generate class objects from the contents of the class file into JVM.

So what is the parental delegation model?

In a word, the parent delegate model is that the child class loader first asks the parent class loader to find the class to load, and the parent class continues to request its parent class to the top level, and if the parent class loader does not find the requested class, the subclass loader will try to load it, so that it goes up and down layer by layer.

Each class loader has a fixed path to find the class, and there are three kinds of loaders in JDK8.

Launch the classloader (Bootstrap ClassLoader), which is part of the virtual machine itself, implemented in C++, and is mainly responsible for loading

In the\ lib directory or in the path specified by-Xbootclasspath and the file name is recognized by the virtual machine. It is the father of all classloaders.

Extension class loader (Extension ClassLoader), which is implemented by Java and independent of virtual machines, and is mainly responsible for loading

The class library in the\ lib\ ext directory or the path specified by the java.ext.dirs system variable.

Application class loader (Application ClassLoader), which is implemented by Java and independent of virtual machines. It is mainly responsible for loading the class library on the user classpath (classPath), which is the default loader in our program if we don't implement a custom class loader.

Why is the parental delegation model proposed?

In fact, it is to enable the basic classes to be loaded correctly and uniformly.

As can be seen from the above figure, if you also define a java.lang.Object class, the parent delegation mode will delegate this request to the startup class loader, which scans the\ lib directory to find the java.lang.Object class defined by jdk to load, so it will not load the java.lang.Object class you wrote at all, which can avoid some programs accidentally or intentionally overwriting the basic class.

At this point, we have made it clear what parental appointment is and why. Next, let's take a look at three times of destruction.

The first destruction

Before jdk 1.2, there was no parent delegation model, but there was an abstract class called ClassLoader, so someone inherited this abstract class and overridden the loadClass method to implement a user-defined class loader.

The parent delegation model will be introduced in 1.2. in order to be forward compatible, the loadClass method has to be retained so that it can be rewritten. A new findClass method has been created for users to rewrite, and calls on people not to rewrite loadClass but to rewrite findClass.

This is the first time to break the parental delegation model, because the logic of parental delegation is on loadClass, but it allows you to rewrite loadClass, which can break the delegate logic.

The second destruction

The second destruction refers to situations such as JNDI, JDBC, and so on.

First of all, you need to know what SPI (Service Provider Interface) is, which is extension-oriented, that is, I define a rule, SPI, that is, how to implement it by the extender.

Just like the JDBC we are familiar with.

MySQL has the JDBC implementation of MySQL, and Oracle has the JDBC implementation of Oracle. No matter how you implement it internally, you database vendors have to follow me anyway, so we Java developers can easily call the database operation, so this SPI is defined in the Java core package.

All the classes in the core package are loaded by the startup class loader, but its hand can only touch the path specified by\ lib or Xbootclasspath, and the rest is beyond its reach.

In our user-defined classpath, the implementation class of JDBC can only be loaded by the application class loader, so the startup class loader can only delegate subclasses to load the specific implementation provided by database vendors, which violates the bottom-up delegation mechanism.

The specific solution is to build a thread context classloader, which is the application classloader by default through setContextClassLoader (), and then use Thread.current.currentThread (). GetContextClassLoader () to get the classloader to load.

This is the second time to destroy the parental delegation model.

The third destruction

This damage is to meet the needs of hot deployment, non-downtime update is very important for the enterprise, after all, downtime is a big deal.

OSGI uses the custom class loader mechanism to complete the modular hot deployment, but the class loading mechanism it implements does not fully follow the bottom-up delegate. There are many class loader lookups between levels, so you can do some research on your own if you are interested.

This is the third destruction.

The fourth destruction

After JDK9 was introduced into the module system, the implementation of the class loader actually made a wave of updates.

For example, the extension class loader is renamed to the platform class loader, the core class loader is assigned to do some division, the platform class loader undertakes more class loading, the above-mentioned-Xbootclasspath and java.ext.dirs are also invalid, and things such as rt.jar are also removed, stored in the jimage file and accessed through the new JRT file system.

When you receive a class load request, you will first determine whether the class is defined in the named module, load it yourself if there is a definition, and delegate it to the parent class if not.

The relevant knowledge points about JDK9 will not be carried out, and those who are interested will consult by themselves.

So this is the fourth destruction.

Other points of attention

First of all, although it is a subclass parent class, the relationship between loaders is not inheritance, but composition.

If you take a look at the code, it's clear. The logic is as follows:

In JVM, the uniqueness of a class is determined by both the class loader instance and the fully qualified name of the class, that is, even if the class loaded by the same class file is loaded with different class loader instances, these are two classes in JVM's view.

At this point, the study on "what is the three-time destruction of the parental delegation model of Java" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.