简单的JVM类加载机制

忙里偷闲，赶紧记录下来类加载机制，方便以后回顾

JVM类加载机制

JVM把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。

特点：类型的加载、连接和初始化过程都是在程序运行期间完成的。

类加载生命周期

上述的几个过程中：加载、验证、准备、初始化的顺序是确定的，而其中的解析则也有可能在初始化后进行

类的主动引用（有且只有会触发初始化）：

1、 遇到new、getstatic、putstatic、或invokestatic 时，若没有进行初始化则先触发初始化。
2、 使用java.lang.reflect包方法对类进行反射调用的时候的那个类
3、 当初始化一个类的时候，若父类没有初始化，则先初始化父类
4、 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类）
5、 当使用(JDK1.7) 若一个java.lang.invoke.MethodHandle实例最后解决方法的句柄，且对应的类没有初始化

除此之之外，其他引用类的方式都不会触发初始化，且通称为被动引用

举个被动引用例子（结果是只触发了父类的初始化）：

接口与类的加载过程区别：

当一个类初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候才会初始化。

类加载详细过程

加载
加载阶段主要完成以下几件事情

1、通过一个类的全限定名来获取定义此类的二进制字节流
2、将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口（Class类比较特殊，虽然时对象但存放在方法区中）

验证
此阶段确保class文件的字节流中包含的信息符合当前虚拟机的要求，且不会危害虚拟机的安全。

验证大致分为下面四个阶段：

1、文件格式验证：是否以魔数0xCAFEBABE（咖啡宝贝）开头，关于魔数的介绍可以参考百度百科；主、次版本号是否在当前虚拟机处理范围之内等等
2、元数据验证： 是否有父类、父类是否继承了不允许被继承的类等等
3、字节码验证： 对类的方法体进行校验分析，保证被校验的方法在运行时不会有危害虚拟机安全的事情
4、符号引用验证： 将符号引用转化为直接引用验证，通过对字符串描述的全限定名是否能找到对应的类等等

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。

注意：
1、上述的类变量（被static修饰的变量）不包括实例变量，实例变量将会在对象对实例化时随着对象一起分配在Java堆中。初始值 是指默认值，当然final修饰的变量不满足上述要求

解析

解析阶段是虚拟机将常量池内的符号引用转换为直接引用的过程。解析包含：类或接口的解析、字段解析、类方法解析、接口方法解析。

直接引用和符号引用的区别

符号引用仅是一组没有任何实际意义的字面量而已，与虚拟机的内存布局无关，且引用的对象并不一定已加载到内存中。
直接引用则是直接指向目标的指针，和虚拟机内存布局有关，若存在直接引用则对象必存在。

初始化

类初始化是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。

初始化阶段是执行类构造器（）方法的过程

1、< clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。
2、< clinit>（）方法与实例构造器< init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的< clinit>（）方法执行之前，父类的< clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的< clinit>（）方法的类肯定是java.lang.Object。
3、< clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成< clinit>（）方法。
4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成< clinit>（）方法。但是接口鱼类不同的是：执行接口的< clinit>（）方法不需要先执行父接口的< clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的< clinit>（）方法。
5、虚拟机会保证一个类的< clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的< clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行 < c linit>（）方法完毕。如果在一个类的< clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

由于父类的< clinit>（）方法先执行，所以结果是2

当然啦：
如果我们颠倒一下Father类中“public static int a = 1;”语句和“static语句块”的顺序，程序执行后，则会打印出1。很明显是根据规则1，执行Father的（）方法时，根据顺序先执行了static语句块中的内容，后执行了“public static int a = 1;”语句。
另外，在颠倒二者的顺序之后，如果在static语句块中对a进行访问（比如将a赋给某个变量），在编译时将会报错，因为根据规则1，它只能对a进行赋值，而不能访问。

类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类的加载阶段。对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在就Java虚拟机中的唯一性，也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”包括了代表类的Class对象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。
站在Java虚拟机的角度来讲，只存在两种不同的类加载器：

• 启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分。

• 所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

  站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：

• 启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
• 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。

• 应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

  应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：
  1）在执行非置信代码之前，自动验证数字签名。
  2）动态地创建符合用户特定需要的定制化构建类。
  3）从特定的场所取得java class，例如数据库中和网络中。

事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息，应用服务器也大都使用了自定义的ClassLoader技术。
这几种类加载器的层次关系如下图所示：

从以上描述中，我们可以总结出如下四点：

1、类的加载过程采用委托模式实现

2、每个 ClassLoader 都有一个父加载器。

3、类加载器在加载类之前会先递归的去尝试使用父加载器加载。

4、虚拟机有一个内建的启动类加载器（bootstrap ClassLoader），该加载器没有父加载器，但是可以作为其他加载器的父加载器。

　　Java 提供三种类型的系统类加载器。第一种是启动类加载器，由C++语言实现，属于JVM的一部分，其作用是加载 /lib 目录中的文件，并且该类加载器只加载特定名称的文件（如 rt.jar），而不是该目录下所有的文件。另外两种是 Java 语言自身实现的类加载器，包括扩展类加载器（ExtClassLoader）和应用类加载器（AppClassLoader），扩展类加载器负责加载\lib\ext目录中或系统变量 java.ext.dirs 所指定的目录中的文件。应用程序类加载器负责加载用户类路径中的文件。用户可以直接使用扩展类加载器或系统类加载器来加载自己的类，但是用户无法直接使用启动类加载器，除了这两种类加载器以外，用户也可以自定义类加载器。

上图中的这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器，当然，它们之间的父子关系并不是通过继承关系来实现的，而是使用组合关系来复用父加载器中的代码。该模型在JDK1.2期间被引入并广泛应用于之后几乎所有的Java程序中，但它并不是一个强制性的约束模型，而是Java设计者们推荐给开发者的一种类的加载器实现方式。
双亲委派模型的工作流程是：

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

使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是Java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。

然而但是也有例外

双亲委派模型让我们加载基础类的时候都是同一个基础类，但我们有时候可能需要在基础类中回调用户代码怎么办呢？“基础类中回调用户代码”可能不大好理解，我们列举一个例子来说明：Java提供了很多服务提供者接口（SPI，Service Provider Interface），允许独立厂商（第三方）为此提供实现。常见的SPI有：JNDI、JDBC、JAXP等。这些接口由Java的核心库来提供，所以问题就在于，SPI的接口是Java核心库的一部分，它们是由启动类加载器来加载的。SPI实现的Java类一般是由应用程序类加载器（Application ClassLoader）来加载的。启动类无法找到SPI的实现类，因为它只加载核心库（SPI的实现类由第三方提供）。它也不能代理给应用程序类加载器，因为它又是应用程序类加载器的父类，双亲委派模型又会将它交给启动类来加载。所以在这个时候我们就要“打破”这个“双亲委派模型”。

这个时候，线程上下文类加载器（Thread Context ClassLoader）很好地解决了这个问题。
Thread类中有

getContextClassLoader()
和setContextClassLoader(ClassLoader cl)方法
用来获取和设置上下文类加载器，如果没有setContextClassLoader(ClassLoader cl)方法通过设置类加载器，那么线程将继承父线程的上下文类加载器，如果在应用程序的全局范围内都没有设置的话，那么这个上下文类加载器默认就是应用程序类加载器（Application ClassLoader），换句话说Java默认的线程上下文类加载器就是应用程序类加载器(AppClassLoader)。通过线程上下文来加载第三方库jndi实现，而不依赖于双亲委派。大部分Java Application服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务（所以理解线程上下文类加载器，更能让我们理解Tomcat等服务器的实现原理、工作方式）。

感谢《深入理解Java虚拟机》

博客：
http://blog.csdn.net/ns_code/article/details/17881581
https://www.cnblogs.com/paddix/p/5268559.html

小结

这一部分真是伤脑细胞，需要十分强悍的基础知识和能力才能够了解到JVM中类加载机制中的奥妙，先mark下，从类的加载过程：加载、验证、准备、解析和初始化，以及最后的类加载器中的双亲委派模型和线程上下文类加载器，讲的还是很精彩的！