虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
推荐：IBM
推荐：IBM
要点
动态加载
在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的。Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
类加载时机
整个生命周期包括：
- 遇到 new、getstatic、putstatic、invokestatic这四条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这四条指令的最常见的java代码场景是：使用 new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
- 使用 reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
- 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
- 虚拟机启动的时候初始化主类
当一个类在初始化时，要求其父类全部都已经初始化过了，但是接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正用到了父接口的时候才初始化.
子类引用父类的静态字段，不会导致子类初始化 通过数组定义来引用类，不会触发此类的初始化，但会加载这个引用类。 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
类加载过程
- 加载： 非数组类的加载基于双亲委派。数组类本身不是通过类加载器创建，它是由虚拟机直接创建的。
- 通过一个类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在内存中生成一个代表这个类的Class对象，作为方法区这个类的各种数据访问的入口。在 HotSpot中Class对象比较特殊放在了方法区。
- 验证：确保Class文件的字节流中包含的信息符合当前虚拟机的要求
- 准备：
- 解析：
- 初始化：
双亲委派
Java 中类加载器大致可分成两类，一类是系统提供的，另外一类则是由 Java 应用开发人员编写的。系统提供的类加载器主要有下面三个：
- 启动类加载器（Bootstrap ClassLoader）: 负责将存放在JAVA_HOME\lib目录下或者-Xbootclasspath参数所制定的路径中的并且是虚拟机识别的（仅按照文件名识别，如rt.jar）类库加载到虚拟机内存中
- 扩展类加载器(Extensions ClassLoader)：由 ExtClassLoader实现，负责加载JAVA_HOME\lib\ext目录下，或Java.ext.dirs系统参数所指定路径下的所有类库
- 系统类加载器（System ClassLoader）: 由 AppClassLoader实现，负责加载用户类路径classPath上所指定的类库
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间.
双亲委派的用处？
- 安全性：对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
- 隔离性：不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。
初始加载器 和 定义加载器
真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类的加载工作是通过调用 defineClass来实现的；而启动类的加载过程是通过调用 loadClass来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。
两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。如类 com.example.Outer 引用了类 com.example.Inner，则由类 com.example.Outer的定义加载器负责启动类 com.example.Inner的加载过程。
破坏双亲委派模型
- 重写loadClass方法会导致双亲委派失效
- 线程上下文类加载器(默认为应用程序类加载器)，加载所需的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作
- 在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更复杂的网状结构
Tomcat
在 tomcat中，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。
绝大多数情况下，Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则：
- 每个 Web 应用自己的 Java 类文件和使用的库的 jar 包，分别放在 WEB-INF/classes和 WEB-INF/lib目录下面。
- 多个应用共享的 Java 类文件和 jar 包，分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
- 当出现找不到类的错误时，检查当前类的类加载器和当前线程的上下文类加载器是否正确。
