A deep understanding of the java ClassLoader

A deep understanding of the java ClassLoader

The class loader is used to load Java classes to Java virtual machines. Generally, Java virtual machines use Java classes as follows: Java source programs (. java files) are converted to Java Byte Code (. class files) after being compiled by the Java compiler ). The Class Loader reads the Java byte code and converts itjava.lang.ClassClass. Each such instance is used to represent a Java class. ThenewInstance()Method to create an object of this Class, that is, a omnipotent Class object.

The class loaders in Java can be roughly divided into two types: one is provided by the system, and the other is compiled by Java application developers. The system provides the following class loaders:

• Bootstrap class loader: it is used to load the core library of Java. It is implemented using native code and does not inherit fromjava.lang.ClassLoader.
• Extensions class loader: used to load Java extension libraries. The Java virtual machine provides an extension library directory. This class loader searches for and loads Java classes in this directory.
• System class loader: it loads Java classes according to the CLASSPATH of Java applications. Generally, Java application classes are loaded by them. You can useClassLoader.getSystemClassLoader()To obtain it. The output of the following code shows the tree structure of classloader.

  public class ClassLoaderTest {public static void main(String[] args){ ClassLoader loader = ClassLoaderTest.class.getClassLoader();         while (loader != null) {             System.out.println(loader.toString());             loader = loader.getParent();         } }}

  
  The Return Value of the loader and toString () method is equivalent to the following expression:

   getClass().getName() + '@' + Integer.toHexString(hashCode())

  The program output is as follows:

  Sun. misc. Launcher $ AppClassLoader @ 70a0afab
  Sun. misc. Launcher $ ExtClassLoader @ 456d3d51
  

  The first output isClassLoaderTreeClass Loader, that is, the system class loader. It issun.misc.Launcher$AppClassLoaderClass; the second output is the extended class loader, which issun.misc.Launcher$ExtClassLoaderClass. Note that the bootstrap loader is not output here, because some JDK implementations use the bootstrap loader for the parent loader,getParent()Method returnnull.

  After learning about the tree structure of the Class Loader, the following describes the proxy mode of the class loader.
  

  Classloader is used to load classes and is fully responsible for delegation. The so-called full responsibility means that when a classloader loads a Class, the classloader is responsible for loading all the classes that this Class depends on and references, unless it is explicitly loaded using another classloader, the delegate mechanism is to first look for the parent (parent) Class Loader (instead of super, it is not an inheritance relationship with the parent classloader class, you can only search for it from your own class path when the parent cannot be found. In addition, the cache mechanism is used for Class loading, that is, if the Class is saved in the cache, it is directly returned. If the Class is not saved, it is read from the file and converted to the Class, and saved to the cache, this is why we modified the Class but had to restart JVM to take effect.
  
  The process for each ClassLoader to load a Class is as follows:
  1. check whether this Class has been loaded (that is, whether this Class exists in the cache). If there is 8, if not
  2. If the parent classloader does not exist (there is no parent, the parent must be bootstrap classloader), to 4; if so, to 3
  3. Request the parent classloader for loading. If it succeeds to 8, it fails to reach 5.
  4. Request jvm to load from bootstrap classloader.
  5. Search for the Class file (from the Class path related to this classloader ). 6. If not, 7.
  6. Load the Class from the file to 8.
  7. Throw ClassNotFoundException.
  8. Return Class.
  
  

  To sum up, the sequence of class loaders is:
  Bootstrap classloader, extension classloader, and system classloader. This is because of security considerations. Imagine the consequence of loading a destructive "java. lang. system" class by System classloader. This delegate mechanism ensures that even if you have such a class, you can add it to the class path, but it will never be loaded, because this class is always loaded by bootstrap classloader. You can execute the following code:
  System. out. println (System. class. getClassLoader ());
  The result is null, which indicates that java. lang. system is loaded by bootstrap classloader, because bootstrap classloader is not a real ClassLoader instance, but implemented by JVM, as mentioned earlier.
  

  
  

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

  
  

  It is worth a day that tomcat's webappclassloader is equivalent to a user-defined loader, which is created for each web application deployed on an independent tomcat instance. The class loaded by the loader is visible to the class in its own application but invisible to other web applications. It is responsible for loading the class in the path below

  /WEB-INF/classes
  /WEB-INF/lib

  Different from the Agent Mode of the loading class in java2, The webapp xx Class Loader adopts another type of loading mode (this mode is recommended in section 9.7.2 of the Servlet 2.4 specification web Application Classloader ), when a request object loads a class loaded by webappxx Classloader, webappxx Classloader will first search in the local library (WEB-INF, it is different from the traditional way of entrusting the parent loader to search.