类加载器

我一直没有掌握java的类加载器，直到最近我看log4j2的源码时又好好研究了一下，才稍微懂点。在log4j2中有个功能是收集某个包下面的所有的类，以及写在某个文件中的类，这些都是需要classloader来完成的，于是顺着他的思路以及自己做实验我才慢慢稍微掌握了classLoader。

java的classLoader分为好几类，并且是有阶级关系的，一层一层的继承。最跟类是java自带的，这个我们看不到，他负责加载java运行时的一些核心class（比如JAVA_HOME/jre下面的类），这个加载器不需要我们操心，因为他不会给我带来麻烦和不会带来坏处，他是java的底层。还有一个也是不需要操心的——java的拓展类加载器，这个是刚才提到的classLoader的一个子类，也是用来加载一些核心类（我从网上搜，也是说加载JAVA_HOME/jre下面的类）。第三个是系统类加载器，这个继承自刚刚说的第二个classLoader，他负责加载classpath下的类，我们在系统变量里面配置的classpath就是起到这个作用。当我们在程序里面有一段代码时（不是在容器里面运行，而是手动的javac之后 java），我们就会发现他会使用一个叫做sun.misc.Launcher$AppClassLoader 的类加载器，他会加载当前类的原因就是因为classpath里面有个“.”，表示当前的目录下面进行查找，我猜测这个应该就是上面说的系统类加载器。

代码很简单，这里就不上了，记住不是在容器里面跑的，而是调用的 java命令。

 

但是在容器里面执行时就不一样了，比如我们可以在tomcat下有一个app（使用的springmvc），他的有个controller里面的方法如下：

@RequestMapping("a.do")
@ResponseBody
public void a() {
	System.out.println(A.class.getClassLoader());
}

 当访问这个controller的时候就会打印如下的classloader：

WebappClassLoader

  context: /spring

  delegate: false

  repositories:

    /WEB-INF/classes/

----------> Parent Classloader:

org.apache.catalina.loader.StandardClassLoader@3b5b0734

很明显他是apache的一个classloader，也就是tomcat的，所以很明显是tomcat自己写的classloader，然后从/WEB-INF/classes下面加载class。也就是说我们可以自己写classloader来加载指定路径下面的class。在classloader的官方文档（jdk7）中，有这么一句话：Applications implement subclasses of ClassLoader in order to extend the manner in which the Java virtual machine dynamically loads classes：翻译过来是应用程序可以自己实现ClassLoader以创建自己的类加载器，可以拓展jvm加载类的方式。也就是说我们自己定义的classloader必须实现jdk的java.lang.Classloader类（我自己没有手动实验）

 

类加载器是基于父类委托的方式，即每一次加载一个类的时候会先委托给父亲进行加载，如果父亲加载到了就使用父亲找到的那个class，如果父亲没有加载到，才会自己加载。这样做的好处是使得jvm变得更加安全，如果没有父类委托机制的话我们可以写一个classloader，然后加载java.lang.String类，这样所有的String类就会都被改变了，导致jvm无法运行，而如果有了父类加载机制，这样的事情就不会发生，java的核心加载器也就是我们定义的加载器的父类已经加载了jdk的String类，我们即使手动的加载一个我们自己写的java.lang.String也无法成功。