effect
Used to dynamically load class files into memory
Classification
BootStrapClassLoader: called the bootstrap class loader, is the top class loader in the Java class loading hierarchy,
responsible for loading the core class libraries in the JDK, such as: rt.jar, resources.jar, charsets.jar, sunrsasign.jar, jsse .jar, jce.jar, etc. (load some jar packages under jdk/jre/lib/ and class files under jdk/jre/classes)
ExtensionClassLoader: called extension class loader, responsible for loading Java extension class library, loaded by default All jars in jdk/jre/lib/ext/
AppClassLoader: called the system class loader, responsible for loading all jars and class files in the application classpath directory
Users can also define their own ClassLoader according to their needs, and the customized ClassLoader must inherit from the java.lang.ClassLoader class (including Java provides Extension ClassLoader and App ClassLoader)
Bootstrap ClassLoader does not inherit ClassLoader, because it is not an ordinary Java class, the bottom layer is written in C++ and embedded in the JVM kernel. When the JVM starts, the Bootstrap ClassLoader is also started, responsible for loading the core class library, and constructing the Extension ClassLoader and App ClassLoader class loader
class loader principle
ClassLoader uses the parent delegation model to search for classes.
Each ClassLoader instance has a reference to the parent class loader (not an inheritance relationship, but an inclusive relationship).
Bootstrap ClassLoader itself has no parent class loader, but can be used as a parent class loader for other ClassLoader instances.
When a ClassLoader instance needs to load a class, it will first delegate the task to its parent class loader. This process is checked from top to bottom, and
the top-level class loader Bootstrap ClassLoader tries to load first.
If it is not loaded, it will transfer the task to the Extension ClassLoader for loading.
If it is not loaded, it will be transferred to the App ClassLoader for loading.
If it is not loaded, it will be returned to the delegated initiator, and it will go to the specified file. This class is loaded from URLs such as system or network.
If none of them are loaded into this class, a ClassNotFoundException is thrown.
Otherwise, the found class will generate a class definition, load it into memory, and finally return the Class instance object of this class in memory.
Why use this model of parental delegation? Because this avoids repeated loading,
when the parent has already loaded the class, there is no need for the child ClassLoader to load it again.
Considering security factors, let's imagine that if we don't use this delegation mode, we can use a custom String to dynamically replace the String type defined in the java core api at any time, which will have a very big security risk,
and parents The way of delegation can avoid this situation, because String is already loaded by the class loader (Bootstrcp ClassLoader) at startup, so a user-defined ClassLoader can never load a self-written String
unless you change the ClassLoader in the JDK Default algorithm for searching classes.
When the JVM searches for a class, how does it determine that two classes are the same?
When the JVM determines whether two classes are the same, it not only determines whether the two class names are the same, but also determines whether they are loaded by the same class loader.
Only if both are satisfied at the same time, the JVM considers the two classes to be the same.
Even if two classes are the same class bytecode, if they are loaded by two different ClassLoader instances, the JVM will think they are two different classes.
custom class loader
1. Inherit java.lang.ClassLoader
2. Rewrite the findClass method of the parent class
Because JDK has already implemented the algorithm of ClassLoader searching for classes
in the loadClass method, when the class cannot be searched in the loadClass method, the loadClass method will call the findClass method to search for the class, so we only need to rewrite this method.
If there are no special requirements, it is generally not recommended to rewrite the algorithm of the loadClass search class.