JVM学习笔记之类加载器

  之前一直计划学习JVM，但却一拖再拖，实在不应该，早就买了的《深入理解JVM》已经桌上积了一层薄灰，愿从这边博客起，我和阅读到这篇文章的你，都可以慢慢走近JAVA虚拟机的世界。

  总所周知，JAVA之所以流行，不是因为它本身牛逼强大，而是默默在背后支持它的JVM，它让JAVA多了无数种可能。类加载器可以说是JAVA语言的一项创新，也是JAVA语言流行的重要原因之一。

  类加载器负责将.class文件（可能在磁盘上，也可能在网络上）加载到内存中，并为之生成对应的java.lang.Class对象。每当JVM启动时，会形成三个雷加载器组成的初始类加载器层次结构：

类加载器之间的斧子关系和管辖范围图（双亲委派模型）

  从JAVA虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（BootStrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机资深的一部分，从上述的结构图，我们也可以看出，它是“爷爷”一样的存在。另一种，就是其他的类加载器，这些列加载器都由JAVA语言实现，独立于虚拟机外部，并且全部都继承自抽象类java.lang.ClassLoader。

1. BootStrap ClassLoader（启动类加载器），这个类加载器负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数所指定的路径中。启动类加载器无法被JAVA程序直接引用，你在编写自定义类加载器时，如果需要把类加载请求委派给引导类加载器，那直接使用null代替即可。
   
2. Extendsion ClassLoader（扩展类加载器）：这个加载器由sun.misc.Launcher$EctClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
   
3. Application ClassLoader（应用程序类加载器）:这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上的指定类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认的类加载器。

  通过以上，我们应该对类加载器的大致有了一个简单的认识，接下来，我们来谈谈很重要的一点——双亲委派模型的工作过程，也就是父类委托机制。

  如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

  那么，这种机制的优点在于何处呢？如果没有这种机制，由各个类加载器自行去加载的话，假设用户自己编写了一个java.lang.Object类，并放在程序的ClassPath中，那么系统中将出现多个不同的Object类，这时，JAVA类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

  值得一提的是，类加载还采用了cache机制：如果 cache中保存了这个Class就直接返回它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么修改了Class但是必须重新启动JVM才能生效,并且类只加载一次的原因。

 

最后玩一点代码：

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