Dive Java class loader ClassLoader

The ClassLoader (class loader) is used to load Java classes into a Java virtual machine. Generally speaking. Java Virtual machines Use Java classes in such a way that the Java source program (. java file) is converted to a Java bytecode (. class file) after it has been compiled by the Java compiler. The class loader is responsible for reading the Java byte code. and convert it into java.lang.Class An instance of the class. Each of these instances is used to represent a Java class.

This instance newInstance() can be used to create an object of the class, which is the universal class object.

Class loader in Java can be broadly divided into two categories. One is system-provided and the other is written by Java application developers. The system-supplied class loader has the following three main types:

• Boot class loader (bootstrap class loader): It is used to load the Java core library. is implemented using native code. Does not inherit from java.lang.ClassLoader .
• Extended class loader (Extensions class loader): It is used to load the Java extension library. The implementation of the Java virtual machine provides an extension library folder. The loader finds and loads Java classes in this folder.

• System class Loader: It is loaded into Java classes based on the Classpath (CLASSPATH) of the Java application. In general, Java-applied classes are loaded by it.

  Be able ClassLoader.getSystemClassLoader() to get it through.

The output of the following code shows the tree-like structure of the ClassLoader.

public class Classloadertest {public static void main (string[] args) {ClassLoader loader = ClassLoaderTest.class.getClass Loader ();         while (loader! = null) {             System.out.println (loader.tostring ());             Loader = Loader.getparent ();         } }}

The return value of the Loader,tostring () method is equivalent to the following expression:

GetClass (). GetName () + ' @ ' + integer.tohexstring (hashcode ())

The output of the program is as follows:

[Email protected]
[Email protected]

the first output isClassLoaderTreeClass loader , which is the System class loader. It issun.misc.Launcher$AppClassLoaderAn instance of the class, and the second output is an extended class loader. is asun.misc.Launcher$ExtClassLoaderthe instance of the class.

It is important to note that there is no output boot class loader in this case. This is because some JDK implementations are returned to the parent class loader that is the Boot class loader getParent() null .

After understanding the tree-like structure of the class loader, the following describes the proxy mode of the class loader.

The ClassLoader load class uses the overall responsibility of the entrusted mechanism. The so-called overall responsibility, that is, when a classloader loaded into a class, the class depends on and the reference of all the class is also the classloader responsible for loading. Unless it is explicitly loaded with another classloader, the commit mechanism is to first let the parent class loader (not super, which is not an inheritance relationship with the parent ClassLoader Class). Only when the parent is unable to find the time to find out their own classpath.

In addition, the cache mechanism is used for class loading. That is, assuming that the class is stored in the cache, return it directly, assuming that it is not read from the file and converted to class, and stored in the cache. That's why we changed the class but had to start the JVM again.

the process of loading class into each ClassLoader is:
1. Check if this class has been loaded (that is, if there is this class in the cache), false to 8, assuming that there is no 2
2. Assume that the parent ClassLoader does not exist (without the parent, that the parent must be bootstrap ClassLoader), to 4. Assumption exists. to 3
3. Request the parent ClassLoader to load, assuming success to 8. Not successful to 5
4. Request the JVM to load from bootstrap ClassLoader, assuming success to 8
5. Look for the class file (from the classpath associated with this classloader). Found to 6. If not found then to 7.
6. Load class from file, to 8.
7. Throw classnotfoundexception.
8. Return to class.

< Span style= "font-family:arial; Line-height:25.99431800842285px "> summary. The class loader order is:
First bootstrap ClassLoader. Then the extension classloader, and finally the system ClassLoader. The reason for this is because of security considerations. Imagine the consequences of assuming that System ClassLoader "personally" loaded a destructive "Java.lang.System" class.

This trust mechanism ensures that the user, even with one such class, adds it to the classpath, but it will never be loaded. Since this class is always loaded by bootstrap ClassLoader. You can run the following code:
System.out.println (System.class.getClassLoader ());
You will see that the result is null, which means that Java.lang.System is loaded by bootstrap ClassLoader because Bootstrap ClassLoader is not a true ClassLoader instance. It is implemented by the JVM, as already mentioned.

In short, it is the bottom-up check that the class has been loaded and then tries to load the class from the top down.

It is worth mentioning that the webappclassloader of Tomcat is the equivalent of a user-defined loader, created for each Web application deployed on a standalone tomcat instance. the loader-loaded class is visible to classes in its own application, but not visible to other Web applications, and it is responsible for loading classes in the following path

/web-inf/classes
/web-inf/lib

Unlike the proxy mode for loading classes in Java, the WebApp class loader uses a class load pattern (which is recommended in the Servlet 2.4 specification 9.7.2 section Web application ClassLoader). When a request object loads a class that is loaded by WebappClassLoader,WebappClassLoader will first search in the local library (Web-inf). It is different from the traditional way of entrusting to the parent loader for searching.

Dive Java class loader ClassLoader