JVM在执行java的程序的时候，需要解释器首先会加载需要用到的.class文件，然后解释器JVM的由class文件生成的指令集解释成目标机器可以执行的机器语言。在这里面就有一个很重要的问题，JVM的加载机制是什么样的？每个java程序至少有三个类加载器：引导类加载器，扩展类加载器，系统类加载器。引导类加载器负责加载系统类，它是JVM当中的一部分，而且通常是用C语言实现的。引导类加载器没有对应的ClassLoader对象,通常从JAR文件的rt.jar中进行加载。扩展类加载器用于从"jre/lib/ext"目录加载“标准扩展”。可以将JAR文件放到这个目录下，这样即使没有任何类路径，扩展类加载器也可以找到其中的各个类。系统类加载器用于加载应用类。它在由CLASSPATH变量或者-classpath命令行选项设置的类路径中的目录里或者是JAR/ZIP文件里查找这些类。

      类加载器有一种父子关系。除了引导类加载器之外，每个类加载器都有一个父类加载器。根据规定，类加载器会为它的父类加载器提供一个机会，以便加载任何给定的类，并且只有在父类加载器加载失败的时候，它才会加载给定类。这样的规定会导致类加载的加载会从高层传递到底层，先由底层的引导类加载器加载，如果没有加载到，然后逐步调用相邻高层的加载，如果到最高层仍然失败，则加载失败。这个情况类似于冒泡传播机制。  

     通常不用关心类加载的结构，因为当加载类的时候，大多数情况下是因为有类被用到，那么类才会被加载。每个线程都有一个对类加载器的引用，称为上下文类加载器。主线程上的类加载器是系统类加载器。当新的线程创建的时候，它的上下文类加载器被设定创建线程的上下文类加载器。因此，大多数情况下，新建线程的上下文类加载器是系统类加载器。

      类是由它的全名和类加载器来确定的。这项技术在加载来自多处的代码时非常有用。在一个JVM当中看见两个类全名一样并不会引发冲突，原因是类加载器不一样。导致类加载器不一样的原因是不同的系统集成到一起的时候，每个系统的类加载器不一样。

NOTE:这部分当做了解就可以了，不需要考虑太多