In-depth understanding of the Java class loader ClassLoader

The ClassLoader (class loader) is used to load Java classes into a Java virtual machine. In general, Java virtual machines use Java classes in the following way: Java source programs (. java files) are converted to Java bytecode (. class files) after being compiled by the Java compiler. The ClassLoader is responsible for reading the Java byte code and converting it into java.lang.Class An instance of the class. Each such instance 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.

The ClassLoader in Java can be broadly divided into two categories, one for the system, the other for Java application developers. There are three main types of ClassLoader available in the system:

• Boot class loader (bootstrap class loader): It is used to load Java's core library, which is implemented by native code and does not inherit from java.lang.ClassLoader .
• Extension 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 directory. The ClassLoader finds and loads the Java class in this directory.
• System class Loader: It loads Java classes according to the Classpath (CLASSPATH) of the Java application. In general, Java-applied classes are loaded by it. You can ClassLoader.getSystemClassLoader() get it by.

The output of the following code can show the ClassLoader tree structure.

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 ();         } }}

Where 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$AppClassLoaderclass, and the second output is the Extension class loader, which is asun.misc.Launcher$ExtClassLoaderthe instance of the class. It is important to note that there is no output boot class loader here, because some JDK implementations are for the parent class loader to boot the ClassLoader.getParent()method returnsnull.

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

the ClassLoader load class uses the overall responsibility of the delegation mechanism. The so-called overall responsibility, that is, when a classloader loading a class, the class depends on the and reference of all classes are also loaded by this classloader, unless explicitly using another ClassLoader loading The delegate mechanism is to look for the parent class loader (instead of super, which is not an inheritance relationship with the parent ClassLoader Class), only to find it from its own classpath when the parent cannot find it. In addition, the class loading also uses the cache mechanism, that is, if the cache saved this class directly return it, if not only to read from the file and converted to class, and stored in the cache, this is why we modified the class but must restart the JVM to take effect.

the process for each ClassLoader loading class is:
1. Check if this class is loaded (that is, if there is this class in the cache), if there is 8, if not to 2
2. If the parent ClassLoader does not exist (without the parent, the parent must be bootstrap ClassLoader), to 4; if present, to 3
3. Request the parent ClassLoader to load, if successful to 8, unsuccessful to 5
4. Request that the JVM be loaded from bootstrap ClassLoader if successful 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.

To summarize, the class loader order is:
First bootstrap classloader, then extension classloader, and finally system ClassLoader. The reason for this is that for security reasons, consider if System ClassLoader "personally" loads the consequences of a destructive "Java.lang.System" class. This mechanism guarantees that the user, even with one such class, adds it to the classpath, but it will never be loaded, because the class always loads with bootstrap ClassLoader. You can execute the following code:
   system.out.println (System.class.getClassLoader ());

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's worth a day of Tomcat's WebappClassLoader. This is equivalent to a user-defined loader, created for each web app deployed on a standalone tomcat instance. the class loaded by the loader is visible to the classes in its own application, but not to other Web applications, and it is responsible for loading the classes in the following path

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

Unlike the proxy mode of the load class in Java2, the WebApp XX class loader uses another 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 Webappxx Classloader,webappxx Classloader will first search in the local library (Web-inf) in a different way than the traditional delegate to the parent loader.