类加载机制

        Class文件需要加载到内存当初才能真正的使用，下面来介绍Class文件信息加载到内存中有哪些变化。

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

类加载时机

        一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、准备、解析三个部分统称
为连接。

至于什么时候进行加载阶段并没有强制约束，交由虚拟机自己进行实现。但是对于初始化有六种情况需要立即进行初始化而加载、验证、准备自然需要在此之前开始）：

• 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始
  化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：
   ·        使用new关键字实例化对象的时候。
   ·        读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候。
   ·        调用一个类型的静态方法的时候。
• 使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需
  要先触发其初始化。
• 当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
• 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先
  初始化这个主类。
• 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
• 当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有
  这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

有且仅有上面这六种情况会触发初始化，这六种行为被称为对类的主动引用。除此之外，没有触发引用的操作就是被动引用。下面介绍几种被动引用的情况：

子类引用父类，只会初始化父类，子类不会初始化

使用数组不会进行初始化

调用常量不会进行初始化，这里其实在编译阶段通过常量传播优化，已经将此常量的值“hello
world”直接存储在MyUser类的常量池中，调用的是自身的常量池，所以不会初始化

类加载过程

加载

        这个只是类加载的一个阶段，不要搞混。在加载阶段，Java虚拟机需要完成以下三件事情：

• 通过一个类的全限定名来获取定义此类的二进制字节流。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入
  口。

从哪里获取二进制流，这个灵活性非常大，你可以从网络获取也可以从压缩包中获取。

加载阶段可以按照虚拟机默认的引导类加载器来完成，也可以通过自定义的类加载器完成（重写一个类加载器的findClass()或loadClass()方法）。

这里有个特例，就是数组类不通过类加载器加载，而是虚拟机在内存中进行创建，但是数组类的元素类型需要通过类加载器进行加载。

总结：加载阶段做的事情就是将外部二进制流按照虚拟机指定的格式存储到方法区当中，然后会在Java堆内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

注意：其实加载和连接的部分动作是交叉进行的，加载还没完成，连接阶段就可能已经开始了，比如在加载字节码文件时对文件格式的验证动作，但是这两个阶段的开始时间仍然保持着固定的先后顺序。

连接

验证

        验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求。

        验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节
码验证和符号引用验证。这里就不一一介绍了，主要知道是对字节码文件的校验即可，比如是否以0xCAFEBABE开头等等。

准备

        准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段。

        首先是这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值。

当然，加上final之后，编译后就会赋值。

解析

        解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

初始化

        类的初始化阶段是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

        进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。初始化阶段就是执行类构造器<clinit>()方法的过程，但是<clinit>()方法并不是java代码直接编写的方法，是javac编译生成的。

        <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的。

        <clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

类加载器

        比较两个类是否相等，不仅要Class是同一个，并且得是同一个类加载器加载。

双亲委派模型

        在Java虚拟机的角度来看，分为两类：启动类加载器(虚拟机内置，c++实现)，其他所有类加载器(由java实现，独立于虚拟机并且继承与ClassLoader)。

        在开发人员的角度来看，会更加细致一些，分为三层类加载器，双亲委派模型架构，下面来具体介绍：

• 启动类加载器：这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的而且是Java虚拟机能够识别的(按照名称识别，如rt.jar，名称不符即使在lib目录下也不会被加载)类，Java程序无法直接使用该累加器，其他加载器委派任务，直接使用null表示。
• 扩展类加载器：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中的类库。
• 应用程序类加载器：它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

这就是"双亲委派模型"的关系图，要求除了顶层的启动类加载器可以没有父关系，其余的都应该有父关系，这里使用父关系这个词是因为类加器直接并没有用继承，而是组合来服用代码。

委派过程：收到一个加载类请求，类加载器都会委派给上一级直到启动类加载器，父类加载器搜索自己的范围后没有发现该类之后子类加载器才会尝试加载。上面这段逻辑很简单，就在ClassLoader的loadClass方法中，这种关系有许多好处，既保证了基础类的安全性，又保证的类不会被重复加载。

破坏双亲委派模型

        双亲委派模型并不是一个强约束性模型，双亲委派模型主要出现过3次较大规模“被破坏”的情况：

一、

        由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器早已引入，面对已经存在的用户自定义类加载器的代码，无法再以技术 手段避免loadClass()被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一个新的 protected方法findClass()，尽量不要重写loadClass方法破坏双亲委派模型。

二、

        双亲委派很好地解决了各个类 加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础之所以是基础，因为这些类都是用来做被调用的哪一方，但程序设计往往不会始终一致，基础类如果需要调用用户代码怎么解决，例如，JNDI服务，JNDI现在已经是Java的标准服务， 它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的）。它需要调用在ClassPath路径下SPI的代码，启动类不可能去加载这些代码，解决办法就是引入了线程上下文类加载器。

        这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方 法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内 都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

        JNDI服务使用这个线程上下文类 加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为。

三、

        OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为 Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实 现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更 加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

1）将以java.*开头的类，委派给父类加载器加载。

2）否则，将委派列表名单内的类，委派给父类加载器加载。

3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。

4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器 加载。

6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

7）否则，类查找失败。 上面的查找顺序中只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加 载器中进行的，关于OSGi的其他内容，这里就不再展开了。

这个其实和Tomcat破坏双亲委派模型的原理差不多，都是自己实现类加载机制。