转载：java中的类加载器

java虚拟机中可以安装多个类加载器，系统默认的有3个主要的类加载器。
每一个类加载器负责加载对应位置的类。
BootStrap、ExtClassLoader、AppClassLoader
注：类加载器也是java类，当然也会被类加载器所加载，才能够被使用，因此有一个特殊的类加载器就是：BootStrap
BootStrap使用C++写的，在底层去加载java类。因此他不属于ClassLoader类型
二、结构：
1.那么类加载器的结构是什么呢，用以下例子说明：

publicstaticvoid main(String[] args){
// TODO Auto-generated method stub
ClassLoader loader=ClassLoaderTest.class.getClassLoader();//获取本类的类加载器
//用循环来获取类加载器的父加载器
while(loader!=null){
System.out.println(loader);
loader=loader.getParent();
}
}

结果为：

sun.misc.Launcher$AppClassLoader@1372a1a
sun.misc.Launcher$ExtClassLoader@ad3ba4

根据结果可以看出：
ClassLoaderTest这个类的加载器是AppClassLoader，也就是说AppClassLoader加载的是设置的classpath下的类；
AppClassLoader这个类的父加载器是ExtClassLoader。
2.如果把ClassLoaderTest这个类导出为jar包，放入jre/lib/ext文件目录下，则运行结果变成了如下：

sun.misc.Launcher$ExtClassLoader@ad3ba4

根据结果可以看出：
ExtClassLoader这个加载器负责加载ext文件里jar包的类；
如果同时classpath下也有这个类，AppClassLoader将不会加载，这体现出了类加载器的委托机制：
在类要加载的时候，默认是用当前类所在的线程中的加载器去加载，这个加载器将会自动的先去委托他的父加载器去找，依次类推。
自然会找到最上级，由最上级去找他负责的类加载区，如果有，则加载；如果没有，则再去让下一级找...直到由这个类所在线程中的
类加载器去加载，如果还是没有，就会抛出异常：ClassNotFoundException。
这样做的好处：如果在类加载器指定的目录下同时存在相同的类，那么这种机制可以保证从最顶层的类加载器开始加载，不用每一个
加载器都去加载，这样就保证了加载完生成字节码的唯一性，节省了内存空间；减少了加载次数，从而提高了效率。

 

我们分析三种加载器的使用场合。

1.系统类加载器（应用类加载器），这个加载器使用java实现，使用广泛，负责加载classPath中指定的类。

       具体的使用场合是：加载classPath中指定的而扩展类加载器没有加载的类。若扩展类加载器加载了classPath中的类，则系统类加载器则没有机会加载。

       用户定义的类一般都是系统类加载器加载的。

       可以通过：ClassLoader.getSystemClassLoader()获得。

2.扩展类加载器。

      它负责加载Java的标准扩展，一般使用Java实现的，负责加载jre/lib/ext中的类。和普通的类加载器一样。

        可以通过：ClassLoader.getSystemClassLoader().getParent()获得。

3.引导类加载器。

       它负责加载jdk中的系统类，是用C语言实现的。对于java程序无法获得它，像上文中获得扩展类加载器的父类加载器是null。像String，Integer，Double类都是由引导类加载器加载的。

类加载机制的原理是双亲委派机制。

        当加载一个类时，首先把机会让给父类，先让父类加载，若是父类中不能加载，才会自己再加载。（这是孝顺型的，先想到父类）

而那个Tomcat加载器则恰恰相反。

       当加载一个类时，首先自己加载，自己加载不了，则再去找父类帮忙。（这个忘恩型的，先想到自己）