In-depth understanding of Java Virtual Machines Note Seventh Chapter virtual machine loading mechanism and parental assignment model

??

At the point of view of the virtual machine, there are only two different classloader:

??

One is to start the ClassLoader (Bootstrap ClassLoader), which is implemented in the C + + language and is part of the virtual machine itself;

??

The other is all of the other ClassLoader , which are implemented by the Java Language, independent of the virtual machine, and all inherit from Java.lang.ClassLoader.

?

From the Java Developer's point of view, the ClassLoader can also be divided into finer points, as follows:

??

1. Start the class loader (Bootstrap ClassLoader): This classloader is responsible for placing in the <java_home>\lib directory, or is - The Xbootclasspath parameter is specified in the path and is recognized by the virtual function ( only according to the name of the file, such as Rt.jar, the class library whose name does not match is not loaded even if it is placed in the Lib directory The class library is loaded into the virtual machine memory. Startup ClassLoader cannot be used directly by Java programs.

??

2. Extension class loader (Extension ClassLoader): This ClassLoader is implemented by Sun.misc.launcher$extclassloader , which is responsible for loading in the <java_home>\lib\ext directory, or all class libraries in the path specified by the java.ext.dirs system variable, developers can use the extension class loader directly.

??

3. Application class Loader (Application ClassLoader): This ClassLoader is implemented by the sum.misc.Launcher. $AppClassLoader . Since this classloader is the return value of the Getsystemclassloader () method in ClassLoader , it is generally referred to as the System class loader. It is responsible for loading the class library specified on the user's classpath, which the developer can use directly, if the application does not have its own classloader, typically this is the default class loader in the program.

??

Applications are loaded with each other by these three kinds of loaders and, if necessary, can be added to their own defined class loaders. The relationships between these classloader are generally as follows:

??

??

The hierarchical relationship between the class loaders shown in is called the class loader's parental delegation model (Parents delegation models).

??

The parental delegation model requires that the rest of the ClassLoader should have its own parent classloader, in addition to the top-level startup class loader .

??

The parent-child relationship between the ClassLoader is generally not implemented in an inherited relationship , but instead uses the code of the parent loader with the combined relationship .

??

The process of parent delegation model is:

??

If a class loader receives a request for a class load

??

It's not going to try to load this class yourself first.

??

Instead, delegate this request to the parent ClassLoader to complete

??

This is true for every level of ClassLoader

??

So all load requests should eventually be routed to the top-level startup class loader

??

The child loader tries to load itself only when the parent loader has feedback that it cannot fully load the request.

??

??

??

??

??

Destruction of parental delegation model

?

The first "destruction" of the parent delegation model occurs before the parent delegation model-that is, before the JDK1.2 is released.

??

Since the parent delegation model was introduced after JDK1.2 , the class loader and abstract class Java.lang.ClassLoader were present at the time of JDK1.0 .

??

In the face of existing user-defined class loader implementation code,Java designers have to make some compromises when introducing parental delegation models.

??

For forward compatibility, a new proceted method is added to the java.lang.ClassLoader afterJDK1.2 findclass ()

??

Until then, the only purpose for the user to inherit java.lang.ClassLoader is to override the LoadClass () method

??

Because the virtual call Loader's private method when the class is loaded loadclassinternal ()

??

And the only logic of this method is to call your own loadclass ().

??

After JDK1.2 no longer advocates the user to overwrite the loadclass () method, it should write its own class loading logic into the Findclass () method

??

In the logic of the LoadClass () method, if the parent loader fails to load, it calls its own Findclass () method to complete the load, ensuring that the newly written ClassLoader is compliant with the parent delegation model.

?

The second "destruction" of the parent delegation model is caused by the defect of the model itself .

??

The parent delegation model solves the basic class unification problem of each ClassLoader ( the more basic class is loaded by the upper loader )

??

Base classes are referred to as "foundations" because they are always used as APIscalled by called Code.

??

But what if the underlying class calls the user's code again?

?

This is not an impossible thing, a typical example is the JNDI service

??

Its code is loaded by the startup ClassLoader ( put in Rt.jar when JDK1.3 )

??

But the purpose of Jndi is to centrally manage and locate resources, and it needs to invoke the Jndi interface provider (SPI, Service) deployed by the standalone Vendor Implementation Department under the classpath of the application. Provider Interface) , but what if the code that launches the ClassLoader cannot "know"?

?

To solve this dilemma, theJava design team had to introduce a less elegant design: The thread context ClassLoader.

??

This classloader can be set by the Setcontextclassloader () method of the Java.lang.Thread class, and if it is not set when the thread is created, it will inherit from the parent thread A If it is not set at the global scope of the application, the ClassLoader is the application class loader by default. The thread context ClassLoader, theJNDI service uses this threading context class loader to load the required SPI code, which is the parent ClassLoader requesting the subclass loader to complete the class load action. This behavior is actually through the parent delegation model hierarchy to reverse the use of the class loader, has violated the parental delegation model, but this is also a helpless thing. All load actions in Java that involve SPI are basically used in this way, such as jndi,jdbc,jce,jaxb and JBI .

?

The third "destruction" of the parent delegation model was caused by the user's quest for the dynamic nature of the program, such as the advent of OSGi . In the OSGi environment, the ClassLoader is no longer a tree structure in the parent delegation model, but is further developed into a network structure.

In-depth understanding of Java Virtual Machines Note Seventh Chapter virtual machine loading mechanism and parental assignment model