Java Virtual machine learning-slowly pondering the working mechanism of the JVM (2-1) ClassLoader

The working mechanism of ClassLoader

Different classes in the Java application environment are loaded by different classloader.
The default ClassLoader in a JVM are bootstrap ClassLoader, Extension ClassLoader, App ClassLoader, respectively:

• Bootstrap ClassLoader responsible for loading Java base classes, mainly Rt.jar, Resources.jar, Charsets.jar, and class in the%jre_home/lib/directory
  
• Extension ClassLoader responsible for loading Java extension classes, mainly the jar and class under the%jre_home/lib/ext directory
  
• APP ClassLoader is responsible for loading all classes in the classpath of the current Java application.
  

Where Bootstrap ClassLoader is the JVM level, written by C + +, Extension ClassLoader, App ClassLoader are all Java classes, inherited from URLClassLoader superclass.
Bootstrap ClassLoader is initiated by the JVM, then initializes sun.misc.Launcher, sun.misc.Launcher initializes extension ClassLoader, App ClassLoader.

is the ClassLoader load class flowchart to load a class of procedure class examples that illustrate the entire classloader process.

Bootstrap ClassLoader, Extension ClassLoader, App ClassLoader The relationship between the following:

Bootstrap ClassLoader is Extension classloader parent,extension ClassLoader is the parent of app ClassLoader.

But this is not an inheritance relationship, just a semantic definition, basically, every ClassLoader implementation, there is a parent ClassLoader.

The parent of the current ClassLoader can be obtained through the ClassLoader GetParent method. Bootstrap ClassLoader is special because it is not a Java class, so the GetParent method of extension ClassLoader returns NULL.

After understanding the principles and processes of classloader, we can try custom ClassLoader.

Java ClassLoader ClassLoader Working mechanism

A class loader is a component that looks for a class or interface bytecode file to parse and construct an internal JVM object representation. In Java, the class-loader loads a class into the JVM, which takes the following steps:

1. Loading: Find and import class files;

2. Link: Perform the verification, preparation and resolution steps, where the resolution step is optional:

A) Verification: check the correctness of loading class file data;

b) Prepare: Allocate storage space for static variables of class;

c) parsing: The symbolic reference becomes a direct reference;

3. Initialize: Initialize the static variable and static code block of the class.

Class loading work is done by ClassLoader and the like, ClassLoader is an important Java Runtime system component that is responsible for locating and loading class byte files at run time. The JVM generates three ClassLoader at run time: with Loaders, Extclassloader (Extended class loaders), and Appclassloader (System Class loaders). Where the loader is not a subclass of ClassLoader, it is written in C + +, so we do not see it in Java, and the loader is responsible for loading the JRE's core class library, such as Rt.jar,charsets.jar. Both Extclassloader and Appclassloader are subclasses of ClassLoader. Where Extclassloader is responsible for loading the jar class package in the JRE extension directory ext; The Appclassloader is responsible for loading the class package under the Classpath path.

There is a parent-child hierarchy between these three class loaders, which is the parent loader of Extclassloader, and Extclassloader is the parent loader for Appclassloader. By default, using Appclassloader to load application classes, we can experiment with the following:

 Public class classloadertest {    publicstaticvoid  main (string[] args) {    ClassLoader c=thread.currentthread (). Getcontextclassloader ();    System.out.println (c);    System.out.println (C.getparent ());    System.out.println (C.getparent (). GetParent ());    }    }

The results of the operation are as follows:

[Java]

[Email protected]

[Email protected]

Null

From the above results can be analyzed to conclude that the current ClassLoader is Appclassloader, the parent ClassLoader is Extclassloader, grandfather ClassLoader is the root class loader, because in Java can not get its handle, Therefore, NULL is returned.

The difference between ClassLoader and Class.forName

The function in ClassLoader loadclass is used for loading the class file but does not complete the initialization work, while using Class.forName completes the initialization by completing the initialization of the static variable and static code block of the class. Examples are as follows:

The classes that need to be loaded Reflect.java as follows:

 Public classReflect {Private intUserName; Private intpassword; Static{System.out.println ("Reflect static Block"); }     PublicReflect () {System.out.println ("Reflect Constructs"); }     Public intGetUserName () {returnUserName; }     Public voidSetusername (intuserName) {     This. UserName =UserName; }     Public intGetPassword () {returnpassword; }     Public voidSetPassword (intpassword) {     This. Password =password; }    }

The test class Test.java is as follows:

 Public classTest { Public Static voidMain (string[] args) {ClassLoader ClassLoader=Thread.CurrentThread (). Getcontextclassloader (); Try{System.out.println ("Loading with LoadClass in ClassLoader:"); Classloader.loadclass ("Com.uestc.test.Reflect"); System.out.println ("Load with Class.forName ():"); Class.forName ("Com.uestc.test.Reflect"); } Catch(ClassNotFoundException e) {//TODO auto-generated Catch blockE.printstacktrace (); }    }    }

The results of the operation are as follows:

[Java]

Use LoadClass in ClassLoader to load:

Load with Class.forName ():

Reflect static block

It can be seen from the above results that LoadClass does not perform initialization work, and Class.forName () is initialized.

Java Virtual machine learning-slowly pondering the working mechanism of the JVM (2-1) ClassLoader