深入JVM（四）虚拟机类加载机制

代码编译的结果从本地机器码转变为字节码，是存储格式发展的一小步，却是编程语言发展的一大步。

虚拟机类加载机制

虚拟机把描述”类“的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制。
在java语言里，类型的加载，连接和初始化都是在程序运行期间完成的，这种策略虽然会令类加载时稍加一些性能开销，但是会为java应用程序提供高度的灵活性。java的动态扩展就是依据运行期动态加载和动态连接这个特点实现的。
其实拆开了讲就是编写一个面向接口的应用程序，运行的时候再指定实现类。用户通过预定义和自定义类加载器，让应用程序再运行时再加载那个实现类的二进制流作为程序代码的一部分。（这个是我的理解。原话比较复杂而且不太好理解。我反正个人觉得我这么说简单多了。如果理解的有不对的地方欢迎指出。）

类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止。它的整个生命周期包括：

• 加载
• 验证
• 准备
• 解析
• 初始化
• 使用
• 卸载

七个阶段。其中验证，准备，解析三个部分统称为连接。

类的生命周期

加载，验证，准备，初始化和卸载这五个顺序的确定的，类的加载过程必须按照这种顺序按部就班的开始。而解析阶段却不一定。在某些情况下可以在初始化之后进行。这是为了支持java语言的动态绑定。
什么情况下开始类的加载呢？java虚拟机规范没有强制约束，一般由虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范是严格规定了有且只有五种情况必须立即对类进行初始化：

1. new关键字实例化对象，读取或设置一个类的静态字段以及调用一个类的静态方法时。如果这个类没有进行初始化，则要先初始化。

2. 使用java.lang.reflect进行反射调用的时候，如果这个类没有进行初始化，则要先初始化。

3. 当初始化一个类，发现其父类没有进行初始化，则要先初始化其父类。

4. 虚拟机启动时，用户需要指定一个执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类。

5. （这个我没太看懂，查了一些资料差不多就是类似反射的Method调用类的静态块要先初始化）JDK1.7的动态语言支持时，一个java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic，REF_putStatic，REF_invokeStatic的方法句柄，并且这个方法对应的类没有进行初始化，则要先初始化。

java7在JSR 292中增加了对动态类型语言的支持，使java也可以像C语言那样将方法作为参数传递，其实现在lava.lang.invoke包中。MethodHandle作用类似于反射中的Method类，但它比Method类要更加灵活和轻量级。通过MethodHandle进行方法调用一般需要以下几步：
（1）创建MethodType对象，指定方法的签名；
（2）在MethodHandles.Lookup中查找类型为MethodType的MethodHandle；
（3）传入方法参数并调用MethodHandle.invoke或者MethodHandle.invokeExact方法。

MethodType
可以通过MethodHandle类的type方法查看其类型，返回值是MethodType类的对象。也可以在得到MethodType对象之后，调用MethodHandle.asType(mt)方法适配得到MethodHandle对象。可以通过调用MethodType的静态方法创建MethodType实例，有三种创建方式：
（1）methodType及其重载方法：需要指定返回值类型以及0到多个参数；
（2）genericMethodType：需要指定参数的个数，类型都为Object；
（3）fromMethodDescriptorString：通过方法描述来创建。

创建好MethodType对象后，还可以对其进行修改，MethodType类中提供了一系列的修改方法，比如：changeParameterType、changeReturnType等。
Lookup
MethodHandle.Lookup相当于MethodHandle工厂类，通过findxxx方法可以得到相应的MethodHandle，还可以配合反射API创建MethodHandle，对应的方法有unreflect、unreflectSpecial等。
invoke
在得到MethodHandle后就可以进行方法调用了，有三种调用形式：
（1）invokeExact:调用此方法与直接调用底层方法一样，需要做到参数类型精确匹配；
（2）invoke:参数类型松散匹配，通过asType自动适配；
（3）invokeWithArguments:直接通过方法参数来调用。其实现是先通过genericMethodType方法得到MethodType，再通过MethodHandle的asType转换后得到一个新的MethodHandle，最后通过新MethodHandle的invokeExact方法来完成调用。
原文：https://blog.csdn.net/aesop_wubo/article/details/48858931

然后对于这物种出发类进行初始化的场景，是有且只有！除了这五种之外所有引用类的方式都不会出发初始化，称之为被动引用。
接口的加载过程与类的加载过程有一些不同。针对接口需要做一些特殊说明：
接口也有初始化过程，这点与类是一致的。接口与类初始化的最大的不同是上面第三点：当初始化一个类，发现其父类没有进行初始化，则要先初始化其父类。接口不要求初始化其父类接口。只有在真正使用到父接口的时候才会初始化。

类加载过程

加载：
加载是”类加载“过程的一个阶段。加载阶段虚拟机做三件事：

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

（我个人简单的理解：1，通过名字找到类，2，把这个类存起来。3，有人访问这个类根据名字去找存起来的。）
这个从哪里获取没有明确的规定。从zip包读取，就是我们jar，war，ear的基础。从网络中获取典型的应用Applet，运行时计算生成就是动态代理技术的原理。。。还有好多例子，我就不一一说了。
数组类而言，本身不通过类加载器创建。它是由于java虚拟机直接创建的。但数组与类加载器仍然有很密切的关系。因为数组类的元素类型要通过类加载器去创建啊。
验证：
验证是连接阶段的第一步。这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求。并且不会危害虚拟机自身的安全。
java语言本身是相对安全的 语言。但是Class文件不一定是java源码编译来的，所以虚拟机会检查输入流。他要做的检查：

1. 文件格式验证
2. 元数据验证
3. 字节码验证
4. 符号引用验证

准备：
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。这些变量所使用的内存都会在方法去中进行分配。（注意,这里说的变量都是类变量。也就是static修饰的）
这里有个很有意思的事:比如一个类中private static int value = 123；在准备阶段这个value的值是0而不是123.因为在初始化的时候才会把value赋值为123.但是如果这个value是final的，则准备阶段直接赋值123 了。
解析：
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

在java中，一个java类将会编译成一个class文件。在编译时，java类并不知道引用类的实际内存地址，因此只能使用符号引用来代替。比如org.simple.People类引用org.simple.Tool类，在编译时People类并不知道Tool类的实际内存地址，因此只能使用符号org.simple.Tool(假设)来表示Tool类的地址。而在类装载器装载People类时，此时可以通过虚拟机获取Tool类 的实际内存地址，因此便可以既将符号org.simple.Tool替换为Tool类的实际内存地址，及直接引用地址。
总结：JVM对于直接引用和符号引用的处理是有区别的，可以看到符号引用时，JVM将使用StringBuilder来完成字符串的 添加，而直接引用时则直接使用String来完成;直接引用永远比符号引用效率更快，但实际应用开发中不可能全用直接引用，要提高效能可以考虑按虚拟机的思维来编写你的程序。
参考地址

初始化：
类初始化阶段是类加载过程的最后一步。前面类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与外，其余动作都是虚拟机控制和主导。到了初始化阶段，才真正开始执行类中定义的java程序代码。
在准备阶段我们的变量已经被赋一次值了。但是这个是系统要求的初始值。而在初始化阶段，变量的值变成我们程序中指定的值。

类加载器

虚拟机中的“通过一个类的全限定名来获取定义此类的二进制字节流。这个动作放到java虚拟机外部去实现。以便应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为”类加载器“。
类与类加载器
类加载器只用于实现类的加载动作。但是他在java程序中的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性。每一个类加载器都有独立的类名称空间。这句话换个说法：比较两个类是否相等只有在这两个类是由同一个类加载器加载的前提下才有意义。否则都没必要比较，必定不等。
双亲委派模型
从java虚拟机的角度来讲只存在两种不同的类加载器：一种是启动类加载器，另一种就是所有其他的类加载器。
其他的类加载器都是java语言实现，独立于虚拟机外部，并且全都继承自抽象类：java.long.ClassLoader。

绝大部分Java程序都会使用到以下3种系统提供的类加载器：

• 启动类加载器（Bootstrap ClassLoader）
• 应用程序类加载器（Application ClassLoader）
• 扩展类加载器（Extension ClassLoader）

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
双亲委派模型的工作过程是：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。
每一个层次的类加载器都是如此。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。
只有当父加载器反馈自己无法完成这个加载请求时（搜索范围中没有找到所需的类），子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处：类随着它的类加载器一起具备了一种带有优先级的层次关系。
例如类java.lang.Object，它由启动类加载器加载。双亲委派模型保证任何类加载器收到的对java.lang.Object的加载请求，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。
相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并用自定义的类加载器加载，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双薪委派模型对于保证java小恒徐的稳定运做很重要，但是它的实现很简单：

1. 首先，检查目标类是否已在当前类加载器的命名空间中加载。
2. 如果没有找到，则尝试将请求委托给父类加载器（如果指定父类加载器为null，则将启动类加载器作为父类加载器；如果没有指定父类加载器，则将应用程序类加载器作为父类加载器），最终所有类都会委托到启动类加载器。
3. 如果父类加载器加载失败，则自己加载。
4. 默认resolve取false，不需要解析，直接返回。

破坏双亲委派模型
上文说到了双亲委派模型不是一个强制性的约束模型。而是java设计者推荐给开发者的类加载器实现方式。在java的世界大部分类加载器都遵循这个模型。但是也有例外的。 双亲委派模型主要出现过三次较大规模的“被破坏”情况。

• 双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前--即JDK1.2发布之前。由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则是JDK1.0时候就已经存在，面对已经存在 的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的proceted方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的就是重写loadClass()方法，因为虚拟在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass()。JDK1.2之后已不再提倡用户再去覆盖loadClass()方法，应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型的。
• 双亲委派模型的第二次“被破坏”是这个模型自身的缺陷所导致的，双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用代码调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢。
  这并非是不可能的事情，一个典型的例子便是JNDI服务，它的代码由启动类加载器去加载(在JDK1.3时放进rt.jar)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用独立厂商实现部部署在应用程序的classpath下的JNDI接口提供者(SPI, Service Provider Interface)的代码，但启动类加载器不可能“认识”之些代码，该怎么办？
  为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个；如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。了有线程上下文类加载器，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI,JDBC,JCE,JAXB和JBI等。
• 双亲委派模型的第三次“被破坏”是由于用户对程序的动态性的追求导致的，例如OSGi的出现。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构。

本章小结

介绍了类加载过程的“加载”，“验证”，“准备”，“解析”和“初始化”五个阶段中的虚拟机的动作。还介绍了类加载器的工作原因及其对虚拟机的意义。

全文手打不易（我引用中的内用是别人的帖子，我注明出处链接了。剩下的都是照着书一个字一个字敲的。虽然看起来内容有的一样）。如果你觉得稍微帮到了你一点点，请点个喜欢点个关注。有不同意见或者问题的欢迎评论或者私信。祝大家工作生活都顺顺利利吧。