This is the 20th day of my participation in the August Text Challenge.More challenges in August

preface

In the previous section, we looked briefly at the STEPS of the JVM class loader and looked at the details of the JVM class loading steps in detail. This section will continue with the details of the parent delegate mechanism. Parent delegation mechanism is an important loading mechanism of THE JVM class. It is the underlying design of the JVM class inheritance structure and the core step of the JVM class loading. Tomcat is commonly used to break the parent delegation mechanism, which is also something to understand.

An overview of the

The following is a summary of the JVM execution engine in the book:

Virtual machine and class loading mechanism overview master parent delegate model three layer model start loader extended class loader destruction: Translated into platform loaders in JDK9 Application class loaders Osgi Model What is a class loader Learn about the role of class loaders in practical use The impact of Java modularity on the Parent Delegate model Six steps for Class Loading Load Connection Validation Prepare parse Initialization Use UnloadCopy the code

In this paper, the content

  1. Describes the basic principles of parental delegation
  2. The impact of modularity on class loaders

Mind mapping

Below is the corresponding curtain mind mapping address: www.mubucm.com/doc/6v9RE2g…

Class and classloader

In the first article of this series, we explained that class loaders are the core of loading classes. When we write Java files that are compiled by the JVM as.class files and loaded into the JVM, they are converted into bytecode instructions, and we complete our programs by executing bytecode instructions. In order for a class to be loaded, it needs to be known by the JVM, and that’s what the classloader is for, of course.

Custom class loaders

The book gives an example of a custom classloader, which is posted directly here. What the classloader does is simply build a class load, but at the end of the instanceof operation, the result is false because the classloader loads custom classes, not classes generated by the JVM.

It can also be considered that if there is a custom loader, the “load” operation needs to be performed during class loader judgment. Because here it has two loaders.

public class ClassLoaderTest {

    public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
        ClassLoader myLoader = new ClassLoader() { @Override
        publicClass<? > loadClass(String name)throws ClassNotFoundException { try {
            String fileName = name.substring(name.lastIndexOf(".") + 1) +".class"; InputStream is = getClass().getResourceAsStream(fileName);
            if (is == null) {
                return super.loadClass(name); }
            byte[] b = new byte[is.available()]; is.read(b);
            return defineClass(name, b, 0, b.length);
        } catch (IOException e) {
            throw newClassNotFoundException(name); }}}; Object obj = myLoader.loadClass("com.headfirst.classloader.ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());
        System.out.println(obj instanceof com.headfirst.classloader.ClassLoaderTest);
    }/ * run results: class com. Headfirst. This. ClassLoaderTest false * /
}
Copy the code

What is the parent delegate mechanism?

The parent delegate mechanism refers to a type of loading mechanism for the JVM. The class loading structure of the JVM is shown below:

Structure diagram as shown above, will be divided into three layers structure, respectively is to start the class loader, extension class loader and application loader, the three loaders, first of all, through the application to load, if found unable to load class, is delegated to the upward extension of the parent class loader to load, if the same request load load continues to the Internet, Finally, if the top-level startup class fails to load, it is loaded from the top until the custom loader is ready to load, and if it fails to load, an exception is thrown.

The specific workflow for starting class loaders and so on has been covered in earlier articles in this series and is linked directly here:

About IBM’s OSGI

Osgi was an effort made by IBM to standardize JDK modularity. Of course, it has already been replaced by JDK9 modularity. Of course, this can also be said to be a compromise under the commercial competition. But on the whole, the basic class loader architecture is still maintained.

This reminds me of Jrocket and HotSpot merging, which is not nearly as good as the official design, always a bit less.

Here’s how osGi works:

  1. Java.*, the parent class loader is loaded

  2. List of delegate lists that the parent class loader loads

  3. The import list is delegated to the Export Bundle class loader for loading

  4. Look up Bundler’s class path and load your own class

  5. Look for your Fragmet Bundle

  6. Delegate the Bundle’s class load load

  7. Class lookup failed

Challenges to the Java parental delegation model

The parent delegate mechanism has been challenged three times (or four times). Since the parent delegate mechanism was introduced in JDK1.2, a compromise was chosen for forward compatibility, which was overwritten using the findClass() method. However, this method quickly broke down in the subsequent compatibility process. If there is a base type to callback the lower classes such as typical JNDI service is so so, at this time in order to compatible and can only be not so good design is a new thread context class loader, the loader can be understood as did a plug-in in the start the class loader, if the user’s own implements this plug-in, is called the client code, Otherwise it inherits from the parent class’s loader.

This thread context loader is at the heart of Tomcat’s implementation of breaking parental delegation. Not only Tomcat, of course, but many frameworks also use this thread context loader to “fiddle” with class loading.

There isa simple theoretical basis for the discussion of modularity in the book Java8 In Action. However, if you want to go deeper into modularity, there isa book that can be told, and there is no longer a history of OSGI and Jisaw. There is a section on what he did.

Finally, there is the platform class loader, which basically breaks JDK rules and will be described in more detail below. If you simply understand this class loader, you are implementing the thread context loader through the underlying implementation, which has not been very elegant until now. This means that platform classloaders will be able to perform custom loading operations based on the classloaders defined by the module.

Finally, a brief summary of the above content is as follows:

1. The old code compatibility before Jdk1.2, use findClass to avoid loadClass () rewrite 2. JNDI in Thread. SetContextClassLoader () set jdk6 has 3 the serialLoader replace result. 4. The platform loader breaks the original class loading rules, and the underlying compatible implementation of the thread context class loaderCopy the code

Parental delegation model changes after modularization

Leaving aside the other details of modularity for class loading, we’ll jump right into the biggest change since modularity: The extension class loader (Ext) is replaced by the platform loader (PLAFORM). The main change is that the platform loader and application loader are no longer derived from the URLClassLoader, because the BootClassLoader returns NULL and uses the upper loader for compatibility with older loaders. The result will not come back.

While the three-tier classloader and parental delegation architecture is still maintained in JDK 9, the delegation relationship for class loading has changed as well. When class loading platform and application class loader received the request, the delegate to the parent loader before loading, to determine whether the class can enough belonging to a certain system module, if this can be found on the ownership of the relations, must be responsible for * * priority assigned to the module loader * * finished loading, maybe it can be parents to delegate the fourth break? Personally, it’s more of a “thread context loader” with a less elegant design change.

conclusion

The content of this article is also relatively simple, the same understanding can be. It’s important to remember the steps of parental delegation and how it works.

Write in the last

The next article will cover dispatching, which is a very important part of the JVM, to learn more about overloading, polymorphism, and overwriting.