深入类加载器----类加载器的分类和等级

              深入类加载器(三)----类加载器的分类和等级

 深入类加载器----类加载器的分类和等级_第1张图片深入类加载器----类加载器的分类和等级_第2张图片深入类加载器----类加载器的分类和等级_第3张图片深入类加载器----类加载器的分类和等级_第4张图片深入类加载器----类加载器的分类和等级_第5张图片

 

 

 

 

 

 

       深入类加载器层次结构(三种类加载器)代理加载模式,双亲委托机制

   我们首先要知道在java中,类加载器也是分等级的。最高级的一种加载器是加载java中的核心包下的类。比如说java.ang.String类就是通过这种类加载器进行加载的。下一个等级的就是额外的类加载器。也是加载一些类的。再下一级的就是应用程序的类加载器。再下一级的就是自定义的类加载器了。但是这几种加载器之间不是继承关系的,而是组合关系的。这是要注意的。

  java中,类加载采用的是代理模式。所谓的代理模式,可以简单的理解为,看起来是这个类加载器进行加载,但其实并不是这个加载器进行加载。这就是代理模式。

  在代理模式中,有一个比较重要的一种是双亲委托模式。所谓的双亲委托模式就是:比如说,我定义了一个类A,在加载类A的时候,首先由自定义的类加载器,再到应用程序的类加载器,再到拓展的类加载器,最后到最高级的加载器。首先是由最高级的加载器进行判断,它是否能够加载这个类,如果能够加载的话,就进行加载。如果不能够进行加载的话,再接下来看一下额外的类加载器能否进行加载。这样一层一层地往下。如果都不能加载的话,那么就会出现错误。这是要注意的。

  双亲委托机制的最大的好处就是可以确保是安全的。

  比如说,我举一个例子:

  我首先定义可java.lang包。然后我在这个package的下面定义了一个String类。由于String类是java中的核心包,理应是由最高等级的那个类加载器进行加载的。我们采用了双亲委托的模式: 由上往下,一层一层进行判断,是否能够加载。首先是在最高等级的那个类加载器当中,发现String类是核心包下的一个类。那么就不会对我们自定义的一个类进行加载了。所以即使我们定义了那个类,我们也不能使用这个类。这就是双亲委托模式的好处,可以确保了安全。但是也并不是所有的类加载的过程都是采用双亲委托模式的。比如Tomcat服务器采用的就不是双亲委托模式,它的加载的过程和双亲委托模式是正好相反的。但是也是代理的模式。

 

 

 

 

 

 

 

 

 package com.lg.test;

 

public class Demo02 {

public static void main(String[] args){

System.out.println(ClassLoader.getSystemClassLoader());

System.out.println(ClassLoader.getSystemClassLoader().getParent());

//为什么最后一个类加载器显示的是null呢。其实也是很容易理解的。

//由于这个最高等级的类加载器是使用原始代码进行加载的。也就是实用c++或者c进行编写的。

//所以在java中加载不出来。

System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());

//这里显示的是类加载的路径。由于bin目录下放置的都是一些类的编译成的class文件。所以

//会从这里进行加载。这是要注意的。

System.out.println(System.getProperty("java.class.path"));

String info="liguo";

//通过这个我们发现,我们定义的java.lang.String下的包并没有被使用

//并且我们发现类加载器是null。那么通过代理模式下的双亲委托模式,我们就可以保证类加载的

//安全性。这是要注意的。

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

System.out.println(info.getClass().getClassLoader());

}

 

}

 

最后的输出的结果为:

sun.misc.Launcher$AppClassLoader@4e0e2f2a

sun.misc.Launcher$ExtClassLoader@2a139a55

null

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

liguo

null

 

 

你可能感兴趣的:(java虚拟机)