Java ClassLoader Principle Analysis

The load process of a class refers to the fully qualified name of a class to obtain a binary byte stream describing this class, and convert it into the data structure of the method area, thus generating a Java.lang.Class object as a portal for various data accesses of the method area. This process is done through the class loader (ClassLoader) in Java.

The class loader is used to load classes (class) into the JVM . The JVM specification defines two types of class loaders: The start-in loader (bootstrap) and the user-defined loader (user-defined class loader).

First, the Java default provides three ClassLoader

The JVM generates three Classloader:bootstrap ClassLoader, Extension ClassLoader, and Appclassloader (System ClassLoader) at run time.

1. Bootstrap ClassLoader(startup class loader) is responsible for loading the%java_home%/lib directory or the path specified in the-xbootclasspath parameter, and is the virtual machine-recognized (by name) class library loaded into the JVM.

It can also be defined by the-xbootclasspath parameter. The ClassLoader cannot be instantiated by Java code because it is part of the JVM itself.

2,Extension ClassLoader(Extension class loader) is responsible for loading all the class libraries in the%java_home%/lib/ext;

As long as the jar package is placed in this location, it will be loaded by the virtual machine. A common, similar problem is that you put the low version of MySQL driver accidentally placed here, but your Web application lib has a new JDBC driver, but how all error, such as not support JDBC2.0 DataSource, Then you should be careful that your new JDBC may not be loaded. This is the delegate phenomenon of ClassLoader. There are common log4j, common-log, and dbcp problems, because they can easily be plugged into the Ext directory, or the Common/lib directory under Tomcat

3. Application ClassLoader: Also known as the System Classloaer (the class library that loads the%classpath% path) and other custom ClassLoader. By default, it is the parent of any classloader created by the user ClassLoader.

The main class of the standalone app we created is also loaded by default (via Thread.CurrentThread (). Getcontextclassloader (). The actual development with ClassLoader more time is used to load classpath under the resources, especially configuration files, such as Classloader.getresource (), than FileInputStream directly.

The ClassLoader ClassLoader is hierarchical, that is, the parent-child relationship. Among them, Bootstrap is the father of all ClassLoader. As shown in the following:

Note: In addition to the three classloader provided by the Java default, users can also define their own classloader as needed. These custom classloader must inherit from the Java.lang.ClassLoader class, as well as the additional two classloader provided by Java (Extension ClassLoader and app ClassLoader), but Bootstrap ClassLoader does not inherit from ClassLoader, because it is not an ordinary Java class, the underlying is written in C + +, embedded in the JVM kernel, when the JVM starts, Bootstrap ClassLoader also with the boot, responsible for loading the core class library, and constructs the extension ClassLoader and the app ClassLoader class loader.

Two, parental Commission model

In Java, ClassLoader is loaded using the parental delegation mechanism, using the parent-delegate mechanism to load the class using the following steps:

1, the current ClassLoader first from their own loaded class query whether this class has been loaded, if it has been loaded directly back to the original loaded class;

2, the current ClassLoader cache does not find the loaded class, the delegate parent class loader to load, the parent class loader takes the same policy, first look at its own cache, and then delegate the parent class of the parent class to load, until BOOTSTRP ClassLoader.

3, when all the parent loader is not loaded, and then loaded by the current ClassLoader, and put it in its own cache, so that the next time a load request to return directly.

In this case, you might wonder why Java uses such a delegation mechanism. To understand this, we introduce another conceptual "namespace"about ClassLoader, which refers to determining a class that requires the fully qualified name of the class and the ClassLoader to load the class together. That is, even though the fully qualified names of two classes are the same, but because different classloader load this class, it is a different class in the JVM. Once you understand the namespace, let's look at the delegate model. The use of the Commission model later increased the interaction of different classloader, such as the above, our JDK provided by the class library, such as hashmap,linkedlist, and so on, these classes are loaded by the BOOTSTRP class loader later, No matter how many classloader you have in your program, these classes are actually shareable, which avoids the confusion of different class loaders loading different classes of the same name.

the mechanism of class loading in the JVM--Parental delegation model. This model requires that the rest of the ClassLoader have their own parent loader in addition to bootstrap ClassLoader. The child loader uses the code of the parent loader by combining it, instead of using inheritance. When a ClassLoader loads a class file, it first delegates the parent loader to load the class, passing the top-level ClassLoader (Bootstrap) in turn. If the top layer cannot be loaded (it cannot be found in its search scope), the child loader will attempt to load the class.

the location and order of class lookups are: Cache, parent, self

Three, the principle of ClassLoader loading class

1. Introduction of principle

    ClassLoader uses a parent-commissioned model to search for classes, Each ClassLoader instance has a parent class that loads when a ClassLoader instance needs to load a class, it attempts to search for a class by itself, delegating the task to its parent classloader, which is checked from top to bottom, first by the topmost class loader bootstrap ClassLoader attempt to load, if not loaded, then the task is forwarded to extension ClassLoader attempt to load, if not loaded, then to the app ClassLoader to load, if it is not loaded, then return to the initiator of the delegate, It loads the class into a URL such as a specified file system or network. If none of them are loaded into this class, the ClassNotFoundException exception is thrown. Otherwise, the found class generates a class definition, loads it into memory, and finally returns the class instance object in memory.

2, why use parents to entrust this model?

   because this avoids duplicate loading, when the father has loaded the class, there is no need for the child ClassLoader again load once. Considering the security factors, let's imagine that if we don't use this delegate pattern, we can use a custom string at any time to dynamically replace the type defined in the Java Core API, so there's a very big security risk, and the way that parents delegate, you can avoid this situation, Because the string has been loaded by the Boot class loader (BOOTSTRCP ClassLoader) at startup, the user-defined ClassLoader can never load a string that he writes, Unless you change the default algorithm for the ClassLoader search class in the JDK.

< Span style= "LINE-HEIGHT:22.5PX; letter-spacing:0.5px; font-size:13px; " >

< Span style= "LINE-HEIGHT:22.5PX; letter-spacing:0.5px; font-size:13px; " >

< Span style= "LINE-HEIGHT:22.5PX; letter-spacing:0.5px; font-size:13px; " >

Iv. Custom ClassLoader

Java, in addition to the above-mentioned default provided by the ClassLoader, it also allows the application to customize the ClassLoader, then to customize ClassLoader we need to inherit java.lang.ClassLoader to achieve, Let's take a look at some of the important ways we need to be aware of when customizing ClassLoader:

1.loadClass method

LoadClass Method Declare

 Public Class<?> loadclass (String name)  throws ClassNotFoundException

The above is the prototype declaration of the LoadClass method, the implementation of the above-mentioned parental delegation mechanism is actually implemented in this method. Let's take a look at the code of this method to see how it implements parental delegation.

LoadClass method Implement

 Public Class<?> loadclass (String name) throws ClassNotFoundException {  returnfalse );}

As you can see from above, the LoadClass method calls the Loadcclass (Name,false) method, so let's take a look at another implementation of the LoadClass method.

Class loadclass (String name, Boolean resolve)

protectedSynchronized class<?>loadclass (String name, Boolean resolve) throws ClassNotFoundException {//First , check if the class has already been loaded class C = Findloadedclass (name);//check if class has already been loaded if (c = = null) {      Try {      if(Parent! =NULL) {C= Parent.loadclass (Name,false);//if it is not loaded and the parent class loader is specified, the delegate parent loader loads.   } Else{C= FINDBOOTSTRAPCLASS0 (name);//if there is no parent classloader, the delegate bootstrap loader is loaded}     } Catch(ClassNotFoundException e) {//If still not found, then invoke Findclass in order//To find the class. C= Findclass (name);//if the parent class load is not loaded, it is loaded by its own findclass. }  }  if(Resolve) {resolveclass (c); }  returnC;}

The above code, through annotations, clearly shows how LoadClass's parent delegation mechanism works. One thing we need to note here is that public class<?> loadclass (String name) throws ClassNotFoundException is not marked as final, It also means that we can override this method, that is to say, the parent delegation mechanism can be broken. In addition, it is noted that there is a Findclass method, and then let's say what this method does.

2.findClass

We look at the source code of Java.lang.ClassLoader, and we find that the implementation of Findclass is as follows:

protected Class<?> Findclass (String name) throws ClassNotFoundException {     thrownew  ClassNotFoundException (name);  }

We can see that the default implementation of this method is to throw an exception directly, in fact, this method is left to our application to override. Then the concrete implementation of the implementation of your logic, you can read from the disk, you can also get the class file from the network byte stream, get the class binary can be handed to defineclass for further loading. DefineClass we'll describe it again. From the above analysis, we can draw the following conclusions:

3.defineClass

Let's take a look at the source code of DefineClass First:

DefineClass

protected byte int int len)  Throws classformaterror{      returnnull);}

From the above code we can see that this method is defined for final, which means that this method cannot be override, in fact this is the only entry that the JVM leaves us, through this unique portal, the JVM guarantees that the class file must conform to the definition of the class defined by the Java Virtual Machine specification. This method finally calls the native method to implement the actual class loading.

V. Non-compliance with the "parental delegation mechanism" scenario

It says that the parent delegation mechanism is mainly to realize the interaction problem of the classes that are loaded between different classloader, and the common class is left to the parent loader to load, but there is a case in Java that the class loaded by the ClassLoader needs to be loaded by the child loader. Let's say this happens.

There is an SPI (Service Provider Interface) Standard in Java, using a library of SPI, such as Jdbc,jndi, we all know that JDBC needs third-party-provided drivers to While the drive jar package is placed in the classpath of our application itself, and the API of JDBC itself is part of the JDK, it has been loaded by BOOTSTRP, and how does the implementation class provided by the third-Party vendor load? Java introduces the concept of threading context class loading, the thread ClassLoader is inherited from the parent thread by default, and if not specified, the system ClassLoader (Appclassloader) is the default, so that when a third-party driver is loaded, it can be loaded by the thread's context class loader.
In addition, in order to achieve a more flexible class loader OSGi and some Java app Server also broke the parental trust mechanism.

Reference Link: http://welcome66.iteye.com/blog/2230055

http://www.sczyh30.com/posts/Java/jvm-classloader-parent-delegation-model/

http://blog.csdn.net/xyang81/article/details/7292380

1190000002579346

Java ClassLoader Principle Analysis