Drill-down class loader----class loader classification and ranking

Depth class Loader (iii)----class loader classification and grade

 

 

 

 

 

 

 

Depth class loader hierarchy (three type loader) proxy loading mode, parent-client mechanism

We first need to know that in Java, class loaders are also hierarchical. One of the most advanced loaders is the class that loads the core package in Java. For example, the Java.ang.String class is loaded through such a classloader. The next level is the Extra class loader. It is also loaded with some classes. The next level is the application's ClassLoader. The next level is the custom ClassLoader. But these kinds of loaders are not inheritance relationships, they are combinatorial relationships. This is to be noted.

in Java, class loading takes the form of proxy mode. The so-called proxy mode, can be simply understood as, looks like this class loader to load, but in fact is not the loader to load. This is the proxy mode.

in proxy mode, one of the most important is the parental delegation mode. The so-called parent-delegate model is: for example, I define a Class A, when loading Class A, first by a custom ClassLoader, then to the application's ClassLoader, to the extended class loader, and finally to the highest-level loader. The first is judged by the highest-level loader, whether it can load the class, and load it if it can. If you can't load it, then see if the extra classloader can load. This layer of ground down. If none can be loaded, then an error occurs. This is to be noted.

The biggest benefit of a parental delegation mechanism is that it can be secured.

For example, let me give you an example:

I first define the Java.lang package. Then I defined a string class below this package. Because the string class is the core package in Java, it should be loaded by the class loader of the highest rank. We used the parent-delegate model: from the top down, one layer to determine whether it can be loaded. First, in the class loader at the highest level, the string class is found to be a class under the core package. Then we're not going to load up on one of our custom classes. So even if we define that class, we can't use this class. This is the benefit of the parental delegation model, which ensures security. However, not all class loading processes are based on the parent-delegate model. For example, the Tomcat server is not a parent-delegate model, its loading process and the parent-delegate model is just the opposite. But it's also a proxy model.

 

 

 

 

 

 

 

 

package com.lg.test;

 

Public class Demo02 {

Public static void Main (string[] args) {

System.out.println (Classloader.getsystemclassloader ());

System.out.println (Classloader.getsystemclassloader (). GetParent ());

//Why is the last class loader displaying null? In fact, it is very easy to understand.

//Because this highest class loader is loaded with raw code. That is, practical C + + or C to write.

//So it can't be loaded in Java.

System.out.println (Classloader.getsystemclassloader (). GetParent (). GetParent ());

//This shows the path where the class is loaded. Because the bin directory is placed in a number of classes of the compiled class file. So

//will be loaded from here. This is to be noted.

System.out.println (System.getproperty ("Java.class.path"));

String info= "Liguo";

//Through this we found that the packages under the java.lang.String we defined were not used

//And we find that the class loader is null. Then through the proxy mode of the parents delegate mode, we can ensure that the class loaded

//security. This is to be noted.

System.out.println (info.tostring ());

System.out.println (Info.getclass (). getClassLoader ());

}

 

}

 

The result of the final output is:

SUN.MISC.LAUNCHER$APPCLASSLOADER@4E0E2F2A

Sun.misc.launcher$extclassloader@2a139a55

NULL

C:\Users\liguo\workspace\Others\bin

Liguo

NULL