Java Virtual machine JVM learns the parent delegation mechanism of Class 05 loader

Java Virtual machine JVM learns the parent delegation mechanism of Class 05 loader

class Loader

The class loader is used to load classes into a Java virtual machine.

type of class loader

There are two types of class loaders:

1.JVM comes with the loader:

Root class loader (Bootstrap)

Extension class loader (Extension)

System class loader (systems)

2. User-defined class loader:

Java.lang.ClassLoader, the user can customize how the class is loaded.

the loader that comes with the JVM

The Java Virtual machine comes with the following types of loaders.

1. Root (Bootstrap) class loader:

The loader does not have a parent loader.

It is responsible for loading the virtual machine's core class libraries, such as java.lang.*.

The root ClassLoader loads the class library from the directory specified by the System Properties Sun.boot.class.path.

The implementation of the root ClassLoader relies on the underlying operating system, which is part of the implementation of the virtual machine and does not inherit the Java.lang.ClassLoader class, which is written in C + +.

2. Extension (Extension) class loader:

Its parent loader is the root class loader.

It loads the class library from the directory specified by the Java.ext.dirs system property, or loads the class library from the Jre\lib\ext subdirectory (extended directory) of the JDK's installation directory, which is automatically loaded by the extension ClassLoader if the user-created jar file is placed in this directory.

The extension class loader is a pure Java class and is a subclass of the Java.lang.ClassLoader class.

3. System Class Loader:

Also known as the Application class loader, its parent loader is the extension classloader.

It loads the class from the environment variable classpath or the directory specified by the System Properties Java.class.path, which is the default parent loader for the user-defined ClassLoader.

The System class loader is a pure Java class and is a subclass of the Java.lang.ClassLoader class.

Note: The parent loader concept here does not refer to the inheritance of the class, and the child loader does not necessarily inherit the parent loader (which is actually a combined relationship).

user-defined class loader

In addition to the class loader that comes with the above virtual machines, you can customize your own ClassLoader (user-defined class Loader).

Java provides an abstract class Java.lang.ClassLoader, and all user-defined class loaders should inherit the ClassLoader class.

Parent delegation mechanism for class loading

Starting with JDK version 1.2, the class loading process uses the Father delegation mechanism, which can better ensure the security of the Java platform.

In the parent delegation mechanism, in addition to the root ClassLoader that comes with the Java Virtual machine, the rest of the ClassLoader has only one parent loader, and each loader forms a tree structure according to the parent-child relationship.

When the Java Program request loader Loader1 loads the sample class, Loader1 first delegates its own parent loader to load the sample class, and if the parent loader can load, the load task is completed by the parent loader, otherwise the sample class is loaded by Loader1 itself.

Describe an example of a specific process:

Loader2 first finds whether the sample class has been loaded from its own namespace, and if it is already loaded, returns a reference to the class object representing the sample classes.

If the sample class has not been loaded, Loader2 first request Loader1 on behalf of the load, Loader1 again request the System class loader to load, the System class loader then request the Extension class loader to load, the extension class loader then request the root class loader to load.

If both the root ClassLoader and the extension classloader cannot be loaded, the system ClassLoader attempts to load and, if successful, returns a reference to the class object of the sample class to the Loader1,loader1 and returns it to Loader2, which successfully loads the sample class into the virtual machine.

If the system loader cannot load the sample class, Loader1 attempts to load the sample class, and if Loader1 does not load successfully, LOADER2 attempts to load it.

If all of the parent loaders and loader2 itself cannot be loaded, then the ClassNotFoundException exception is thrown.

The summary is:

Each loader first attempts to load with the parent class, and if the parent class cannot load it tries to load itself, and if it succeeds, it returns the class object to the subclass, and if it fails, tells the subclass to let the subclass load itself. All failures throw an exception.

defining the class loader and the initial class loader

If a class loader can successfully load the sample class, then this classloader is called defining the class loader.

All class loaders that successfully return a reference to a class object, including defining the class loader, which includes defining the class loader and all the sub-loaders underneath it, are called the initial class loaders.

Assuming loader1 actually loaded the sample class, Loader1 is the class loader that defines the sample class, Loader2 and Loader1 as the initial class loader for the sample class.

Parent-Child relationship

It should be noted that the parent-child relationship between the loaders actually refers to the wrapper relationship between the loader objects, rather than the inheritance relationship between the classes.

A pair of parent-child loaders may be two instances of the same loader class, or not.

A parent loader object is wrapped in a child loader object.

For example, Loader1 and Loader2 are instances of the Myclassloader class, and Loader2 wraps Loader1,loader1 as the parent loader for Loader2.

When a custom ClassLoader instance is generated, the system ClassLoader becomes the parent loader for the ClassLoader if it does not specify its parent loader (the ClassLoader constructor method has no parameters).

advantages of the parent delegation mechanism

The advantage of Father's entrust mechanism is that it can improve the security of software system.

Because of this mechanism, the user-defined ClassLoader cannot load reliable classes that should be loaded by the parent loader, thereby preventing unreliable and even malicious code from being loaded by the parent loader.

For example, the Java.lang.Object class is always loaded by the root ClassLoader, and no other user-defined ClassLoader can load Java.lang.Object classes that contain malicious code.

name Space

Each classloader has its own namespace, and the namespace consists of the loader and the classes loaded by all the parent loaders.

In the same namespace, the full name of the class (including the package name of the Class) does not appear in the same two classes.

In different namespaces, it is possible that the full name of the class (including the package name of the Class) will appear in the same two classes.

run-time package

Classes that are loaded by the same class loader that belong to the same package make up a run-time package.

Decide whether the two classes belong to the same run-time package, not only to see if their package names are the same, but also to see if they define the same classloader.

Only classes that belong to the same run-time package can access each other's classes and class members that are visible to the package (that is, the default access level).

Such restrictions can prevent user-defined classes from impersonating the class of the core class library to access the package-visible members of the core class library.

Assume that the user has defined a class java.lang.Spy, and is loaded by the user-defined class loader, because the Java.lang.Spy and core class libraries java.lang.* loaded by different classloader, they belong to different run-time packages. Therefore, java.lang.Spy cannot access the package visible members in the core class library Java.lang package.

Java Virtual machine JVM learns the parent delegation mechanism of Class 05 loader