What is a class loader? In the Class “load” phase, the “code” that uses the fully qualified name of a Class to get the action that describes the binary byte stream of that Class is called a “Class Loader.” This action can be customized;

1. Bootstrap ClassLoader, implemented in C++ language, is a part of the virtual machine itself. 2. All other class loaders, implemented by the Java language, exist independently outside the VIRTUAL machine and all inherit from the abstract java.lang.ClassLoader class.

From a Java developer’s perspective, Java has maintained a three-tier classloader architecture since JDK 1.2;

1. Bootstrap ClassLoader

\jre\lib\rt.jar, resources.jar, charsets. Jar Libraries that are stored in the path specified by the -xbootclasspath parameter;

2. Extension ClassLoader Sun.misc.Launcher$ExtClassLoader,

\jre\lib\ext, all the libraries in the path specified by the java.ext.dirs system variable;

Application ClassLoader: the system’s ClassLoader sun.misc.Launcher$AppClassLoader loads all the libraries in the user’s ClassPath.

Note: There is no inheritance between the class loaders explained above. Both ext and app class loaders are internal classes of the Launcher

Parental delegation model: The working process of the parental delegation model is: If a classloader receives a classload request, it does not try to load the class itself at first. Instead, it delegates the request to the parent classloader. This is true at every level of classloaders, so all load requests should eventually be sent to the top level of the starting classloader. Only when the upper class loader reports that it cannot complete the load request (it did not find the class in its search scope) will the lower class loader attempt to load the class itself; For example, the JDK’s String class will be loaded by the Bootstrap loader, and our own classes will be loaded by AppClassLoad.

Why did the JDK design the parent delegate model, and what were the benefits? 1. Ensure security and prevent the Java core class library from being modified; 2. Avoid repeated loading; 3. Ensure the uniqueness of classes;

If you write a jaa.lang.String class to run, it will throw the following exception;

About parental delegation in JDK source code:Create a breakpoint on the loadClass of the AppClassLoader and run Test03’s main method

This UCP is the JAR files that all of our class loaders need to load, including jre lib and THE JAR files from the MVN repository

If knownToNotExist does not exist, we can check whether it has been loaded

Then super.loadClass(var1, var2);The appLClassLoader does not have a loadClass method. SecureClassLoader does not have a loadClass method Finally, enter the SecureClassLoader’s parent class ClassLoader to enter the loadClass method of the class. Focus on the loadClass and findClass methods of this class

ExtClassLoade is a class that does not have a loadClass method, so it calls the loadClass method of the ClassLoader. Again, this loadClass method that goes into this class

Then it finds that parent is null and goes to the Bootstrap classloaderIt turns out that the native method is called because the bootstrap class loader is written in C++

Since java.lang.InternalError is in the rt.jar package, it will eventually be loaded by the Bootstarp class loader. If c is null, then execute findClass to find your classloader (class name)Define define define define define define define define define define define define define define define define define define define define define define Resolve will resolve when the object is actually instantiated.Finally return to AppClassLoader

Parent delegate summary: If a class loader receives a request for a class load, it first does not attempt to load the class itself. Instead, it delegates the request to the parent class loader, which is true at every level of class loaders. Such as: A class receives a class loading request from the appClassLoader. Instead of trying to load the class itself, the appClassLoader delegates the request to the parent class loader. For example, the parent class that the appClassLoader delegates to is the extClassLoader. When an extClassLoader receives a class loading request, it delegates the request to its parent, bootstrapClassLoader, to load it. If bootstrapClassLoader cannot load it, it passes it to extClassLoader to try to load it. The JVM specification does not explicitly require class loaders to use the parent delegate model for their loading mechanism. It’s only recommended that way, as Tomcat, for example, breaks the parental delegation model. In Tomcat, the classloader mechanism is different from the traditional parent delegation model. When the default classloader receives a load request for a class, it will load it by itself, and when it fails to load the class, it will delegate the load task to its superclass loader, which is also recommended by the Servlet specification.

Why Tomcat breaks the parental delegation model: Because Tomcat is a servlet container, webApp can put multiple apps, such as app1, app2… If app1 and App2 both have classes with the same (fully qualified) name, then the JVM will assume that class has been loaded, so Tomcat uses the webAppClassLoader to load its own apps.