What exactly is ClassLoader ?, ClassLoader thing?

What exactly is ClassLoader ?, ClassLoader thing?

To learn more about ClassLoader, you must first know what ClassLoader is for. As its name suggests, it is used to load Class files to JVM for use by programs. We know that java programs can dynamically load class definitions, and this dynamic loading mechanism is implemented through ClassLoader, so we can imagine the importance of ClassLoader.

Since ClassLoader is used to load classes to JVM, how is ClassLoader loaded? Isn't it a java class?

By default, JDK provides the following ClassLoader types:

1. Bootstrp loader
The Bootstrp loader is written in C ++ and initialized after the Java VM is started. It is mainly responsible for loading % JAVA_HOME %/jre/lib, -The path specified by the Xbootclasspath parameter and the class in % JAVA_HOME %/jre/classes.

1. ExtClassLoader
Bootstrp loader loads ExtClassLoader and sets the parent loader of ExtClassLoader as Bootstrploader. extClassLoader is written in Java, specifically sun. misc. launcher $ ExtClassLoader and ExtClassLoader mainly Load % JAVA_HOME %/jre/lib/ext. All the classes directories in this path and java. ext. class Library in the path specified by the dirs system variable.

2. AppClassLoader
After the Bootstrp loader loads ExtClassLoader, it loads AppClassLoader and specifies the parent loader of AppClassLoader as ExtClassLoader. AppClassLoader is also written in Java, and its implementation class is sun. misc. launcher $ AppClassLoader. In addition, we know that the ClassLoader has a getSystemClassLoader method. This method returns the AppclassLoader. appClassLoader is mainly responsible for loading the class or jar file at the location specified by classpath. It is also the default Class Loader for Java programs.

When running a program, the JVM starts and runs bootstrap classloader. This ClassLoader loads the java core API (ExtClassLoader and AppClassLoader are also loaded at this time), and then calls ExtClassLoader to load the extended API, finally, AppClassLoader loads the Class defined under the CLASSPATH Directory, which is the most basic loading process of a program.

The above describes the role of ClassLoader and the most basic loading process. Next we will explain the ClassLoader loading method, the ClassLoader uses the parent-parent delegation mode for class loading.

Each custom ClassLoader must inherit the ClassLoader abstract class, and each ClassLoader will have a parent ClassLoader. Let's take a look at the ClassLoader. This abstract class has a getParent () method, this method is used to return the parent of the current ClassLoader. Note that this parent is not an inherited class, but a ClassLoader specified when the ClassLoader is instantiated. If this parent is null, by default, the parent of the ClassLoader is bootstrap classloader. What is the use of this parent?

We can consider this situation. Suppose we have customized a ClientDefClassLoader, and we use this custom ClassLoader to load java. lang. string, will the String be loaded by this ClassLoader? In fact, the java. lang. String class is not loaded by the ClientDefClassLoader, but by the bootstrap classloader. Why? This is actually the reason for the parent-parent delegation mode, because before any custom ClassLoader loads a class, it will first delegate its parent ClassLoader to load, only when the parent ClassLoader cannot be loaded successfully will it be loaded by itself. In the above example. lang. string is a class of the core java API, so when using ClientDefClassLoader to load it, The ClassLoader will first Commission its parent ClassLoader for loading. As mentioned above, when the parent of the ClassLoader is null, the parent of the ClassLoader is the bootstrap classloader, so the top layer of the ClassLoader is the bootstrap classloader. Therefore, when it is finally delegated to the bootstrap classloader, bootstrap classloader will return Ss.

Let's take a look at a piece of source code in ClassLoader:

Protected synchronized Class loadClass (String name, boolean resolve) throws ClassNotFoundException {// first check whether the class specified by this name has been loaded Class c = findLoadedClass (name ); if (c = null) {try {if (parent! = Null) {// If parent is not null, call the loadClass of parent to load c = parent. loadClass (name, false);} If else {// parent is null, call BootstrapClassLoader to load c = findBootstrapClass0 (name);} catch (ClassNotFoundException e) {// if the load still fails, call its findClass to load c = findClass (name) ;}} if (resolve) {resolveClass (c) ;}return c ;}

 

From the code above, we can see that the approximate process of loading a class is the same as that in the previous example. When we want to implement a custom class, you only need to implement the findClass method.

Why is this dual-parent delegation used?

The first reason is that this prevents repeated loading. When the parent has loaded the class, there is no need for the sub-ClassLoader to load it again.

The second reason is that considering the security factors, let's think about it. If we don't use this delegation mode, we can use custom strings at any time to dynamically Replace the class types defined in java core APIs, this poses a major security risk. This situation can be avoided by the dual-parent delegation because the String has been loaded at startup, therefore, a user-defined class cannot load a custom ClassLoader.

I have made a rough introduction to the ClassLoader loading mechanism. Next I have to explain another Class related to ClassLoader, that is, class Class, each class file loaded by ClassLoader, in the end, all Class instances will be referenced by programmers. we can regard the Class as a template for common classes. The JVM generates corresponding instances based on this template and is eventually used by programmers.

We can see that there is a static method forName in the Class class. This method serves the same purpose as the loadClass method in the ClassLoader and is used to load the Class, but the two are different in terms of function.

Why do we need to customize classloader?

 

I think the main reasons are as follows: 1. Class isolation. Do not want some classes to be seen by other classes. 2. security factors. For example, if I have a custom Encryption Class file, I can only use my own classloader to parse it into a normal class file and run it. 3. Functional Factors. There are other requirements for the class loader.