Analysis of Java Class Loader

Jvm classLoader architecture:

Bootstrap ClassLoader/start class loader
It is mainly responsible for packaging the core api under the jdk_home/lib directory or the jar specified by the-Xbootclasspath option.
Extension ClassLoader/Extension class loader
It is mainly responsible for packaging the jar package in the jdk_home/lib/ext directory or the jar package in the directory specified by-Djava. ext. dirs.
System ClassLoader/System Class Loader
It is mainly responsible for packaging classes and jar files in the directory referred to by java-classpath/-Djava. class. path.
User Custom ClassLoader/User-defined class loader (subclass of java. lang. ClassLoader)
During the program running, the class file is dynamically loaded through the subclass of java. lang. ClassLoader, reflecting the Dynamic Real-time class loading feature of java.
Classloader features:

Each ClassLoader maintains its own namespace. Two classes with the same name cannot appear in the same namespace.
To implement the Class Loader security mechanism at the top layer of the java Security Sandbox Model, java adopts the "parent-delegate loading chain" structure by default.
 

Why is this dual-parent delegation used?

This avoids repeated loading. When the parent has already loaded the class, there is no need for the sub-ClassLoader to load it again.
Considering the security, let's think about it. If we don't use this delegation mode, we can use custom strings to dynamically Replace the types defined in the java core api at any time, this poses a great security risk, and the dual-parent delegation method can avoid this situation because the String has been loaded at startup, therefore, a user-defined class cannot load a custom ClassLoader.
Java dynamically loads class in two ways:

Implicit is implicit, that is, the class is dynamically loaded using the feature loaded only by instantiation.
There are two explicit modes:
ForName () method of java. lang. Class
LoadClass () method of java. lang. ClassLoader