第七章 虚拟机类加载机制
1、类加载的时机
虚拟机的类加载机制：
虚拟机把描述类的数据从class文件中加载到内存，并对数据进行校验、转换解析和初始化，最终形成了可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
类从被加载到虚拟机内存中开始到卸载出内存为止，他的整个生命周期包括加载、验证、准备、解析、初始化、使用和卸载七个阶段。
加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类加载过程必须按照这种顺序按部就班的开始。而解析阶段不一定在某种情况下，可以在初始化阶段之后再开始，这是为了支持Java运行时绑定。
类初始化的五种情况：
遇到new、getstatic、putstatic和invokestatic这4条指令时，如果类没有初始化时，则需要先触发其初始化。生成这4条指令的最常见Java代码场景是：使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、已在编译期把结果放入常量池的静态字段除外)，以及调用一个类的静态方法。
使用java.lang.reflect包的方法对类进行反射调用时候。
当初始化一个类时，发现其父类没有进行初始化，则需先触发其父类的初始化。
当虚拟机启动时，用户需要制定一个要执行的主类（包含main()方法的那个类），当前类需要先初始化
当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_putStatic、REF_getStatic、REF_invokeStatic的方法句柄，并且此方法句柄所对应的类没有进行初始化时，需要初始化该类。
被动引用：
这五种情况被称为对一个类的主动引用，除此之外所有的引用类的方式都不会触发初始化，称为被动引用。
通过子类引用父类的静态字段不会导致初始化。对于静态变量只有直接定义这个类的字段才会被初始化因此通过子类来引用父类中定义的静态变量不会导致子类的初始化。
父类：
package com.ecut.classload;public class SuperClass{ static { System.out.println("super init!"); } static int value = 1; }
子类：
package com.ecut.classload;public class SubClass extends SuperClass{ static { System.out.println("sub init!"); } }
package com.ecut.classload;/** * 通过子类引用父类的静态字段，不会导致初始化 */ public class NotInitialization1 { public static void main(String[] args) { System.out.println(SubClass.value); } }
运行结果如下：
........
[Loaded com.ecut.classload.SuperClass from file:/D:/code/java/jvm-test/out/production/jvm-test/] [Loaded com.ecut.classload.SubClass from file:/D:/code/java/jvm-test/out/production/jvm-test/]super init! 1
.......通过数组定义来引用类，不会触发此类的初始化
package com.ecut.classload;/** * 通过数组定义来引用类，不会触发此类的初始化 * -XX:+TraceClassLoading */ public class NotInitializatio2 { public static void main(String[] args) { SuperClass[] superClasses = new SuperClass[10]; } }
运行结果如下：
....... [Loaded java.net.Proxy$Type from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] [Loaded com.ecut.classload.SuperClass from file:/D:/code/java/jvm-test/out/production/jvm-test/] [Loaded java.util.ArrayList$Itr from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] [Loaded sun.net.NetHooks from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] [Loaded java.net.Inet6Address$Inet6AddressHolder from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] [Loaded java.lang.Shutdown from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] [Loaded java.lang.Shutdown$Lock from C:\Program Files\Java\jdk1.8.0_121\jre\lib\rt.jar] ........
常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义的常量的类，因此不会触发定义常量的类初始化。
常量类：
package com.ecut.classload;public class ConstClass { public static final String HELLOWORD = "hello world"; static { System.out.println("const init !"); } }
测试类：
package com.ecut.classload;/** * 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义的常量的类，因此不会触发定义常量的类初始化 */ public class NotInitializatio3 { public static void main(String[] args) { System.out.println(ConstClass.HELLOWORD); } }
虽然在源码中引用了ConstClass类中的常量但其实在编译阶段已将此常量值存储在了main方法所在的常量池中，对常量的引用装换成了对自身常量池的引用。
接口在初始化的时候并不要求其父接口全部要完成初始化，只要在真正使用到的时候才会初始化。
2、类加载的过程
加载：
通过一个类的全局限定名获取定义此类的二进制字节流（将字节码文件( .class ) 读入到 JVM 所管理的内存中）。
将这个字节流锁代表的静态存储结构转换为方法区的运行时数据结构。
在内存中生成一个代表这个类的java.lang.class对象，作为方法区这个类的各种数据的访问入口。
验证：
验证的目的是确保class文件的字节流中包含的信息符合当虚拟机的要求，并且不危害虚拟机自身安全。
验证从整体上来看虚拟机的验证阶段大致可以分为四个阶段的检验工作，文件格式验证，元数据验证，字节码验证，符号引用验证。
文件格式验证，保证输入的字节流能正确的被解析并存储到方法区，这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证，字节流才会进入方法区中进行存储。文件格式验证例子，是否是魔数0xCAFEBABE开头，主次版本号是否在当前虚拟机处理范围之内，常量池的常量中是否有被支持的常量类型。
元数据验证，对字节描述信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，目的是对类的元数据信息进行语义分析校验，保证不存在不符合Java语言规范的元数据信息，是对元数据中的数据类型做校验。元数据验证的例子，这个类是否有父类（除了object类都有父类），这个类是否继承了被final修饰的类。
字节码验证，目的是通过数据流和控制流分析确定程序语义是否合法符合逻辑，对类的方法进行验证。字节码验证例子，保证跳转指令不会跳转到方法以外的字节码指令上，保证方法体类型转换时有效。
符号引用验证，发生在将符号引用转换成字节引用的时候，这个转换动作将在解析的时候发生，符号引用是对常量池中各种符号引用的信息进行匹配验证。目的是为了解析的过程可以正常进行。
准备：
准备阶段是正式为类变量分配内存并设置类变量初始化值的阶段，这些变量所使用的内存都将在方法区中进行分配。
这个时候进行内存分配的变量仅包括类变量，这里的初始值通常是数据类型的零值，除了final修饰的变量初始化值为所给定的值。
解析：
是虚拟机将常量池中符号引用替换为直接引用的过程。解析动作主要是针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符类符号引用进行。
符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，但各种虚拟机能接受的符号引用是一致的。
直接引用可以直接指向目标的指针，相对偏移量或是一个能间接定位到的句柄（对象的访问定位有两种，使用句柄的访问方式和使用直接指针访问）
初始化：
初始化阶段，根据程序员通过程序制定的主观计划去初始化类变量和其他资源。 初始化过程是执行类构造器<client>()方法的过程。
编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，而定义在它之后的变量，在前面的静态语句块可以赋值，但不能访问。
在<client>()方法执行之前，父类的<client>()方法已经执行完毕，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
虚拟机会保证一个类的<client>()方法在多线程环境中被正确的加锁、同步，如果多个线程去初始化一个类，那么只会有一个线程去执行这个类的<client>()方法，其他线程都需要阻塞等待。
3、类加载器
类与类加载器：
虚拟机团队把类加载阶段中的通过类的全限定名获取描述此类的二进制字节流的动作放在Java虚拟机之外来实现，以便让应用程序自己决定如何去获取所需类。这个实现代码模块称为类加载器。
只有两个类是有同一个类加载器，加载的前提下是有意义否则即使来源于同一个class文件被同一个虚拟机加载只要加载他们的类加载器不同，那这个类必定不相等。
package com.ecut.classload;import java.io.IOException;import java.io.InputStream; public class ClassLoaderTest { public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException { ClassLoader myClassLoder = new ClassLoader() { @Override public Class<?> loadClass(String name) throws ClassNotFoundException { try { String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class"; InputStream is = getClass().getResourceAsStream(fileName); if (is == null) { return super.loadClass(name); } byte[] b = new byte[is.available()]; is.read(b); return this.defineClass(name, b, 0, b.length); } catch (IOException e) { throw new ClassNotFoundException(name); } } }; Object object = myClassLoder.loadClass("com.ecut.classload.ClassLoaderTest").newInstance(); System.out.println(object instanceof com.ecut.classload.ClassLoaderTest); } }
运行结果如下：
false
类加载器的分类：
启动类加载器（根加载器，Bootstrap ClassLoader）：由C++语言实现（针对HotSpot）,负责将存放在<JAVA_HOME>\lib目录或-Xbootclasspath参数指定的路径中的类库加载到内存中。
扩展类加载器（Extension ClassLoader）：负责加载<JAVA_HOME>\lib\ext目录或java.ext.dirs系统变量指定的路径中的所有类库。
应用程序类加载器（系统类加载器，Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器。
双亲委派模型：
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
工作过程是如果一个类加载器收到类加载的请求，先不会自己去尝试加载这个类，而是把这个请求委派个父类加载器，每一个层级都是这样，因此所有的加载请求最终都会送至顶层启动类中，只有父类加载器无法完成这个请求，才会由子加载器尝试去加载。
作用：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。类随着它的类加载器一起具备了一种带有优先级的层次关系。无论哪个一个类加载器加载object类都由根加载器完成，因此object在程序中各类加载器环境都是同一个类。
双亲委派机制的是实现原理：
public Class<?> loadClass(String name) throws ClassNotFoundException { return loadClass(name, false); } protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 首先，检查类是否已经加载。 Class<?> c = findLoadedClass(name); if (c == null) { long t0 = System.nanoTime(); try { if (parent != null) { c = parent.loadClass(name, false);//看父类加载器有没有加载该类（父委托机制） } else { c = findBootstrapClassOrNull(name);//父类加载器为空，看根加载器（Bootstrap Loader）有没有加载 } } catch (ClassNotFoundException e) { //如果类没有发现抛出ClassNotFoundException } if (c == null) { //如果仍然没有找到，然后调用findClass为了找到类。 long t1 = System.nanoTime(); c = findClass(name); // 这是定义类装入器；记录统计数据 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); sun.misc.PerfCounter.getFindClasses().increment(); } } if (resolve) { resolveClass(c); } return c; } } protected Class<?> findClass(String name) throws ClassNotFoundException { throw new ClassNotFoundException(name); }
先检查是否被加载过，若没有被加载过调用父类的loadclass方法，若父加载器为空则默认使用启动类加载器为父加载器，如果父加载器加载失败就抛出ClassNotFoundException ，再调用自己的findClass方法进行加载。
破坏双亲委派机制模型：
第一次破坏：由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在，为了向前兼容如果父加载器加载失败就抛出ClassNotFoundException ，再调用自己的findClass方法进行加载。这样就可以保证新写出来的类加载器符合双亲委派规则的。
第二次破坏：这个模型自身的缺陷所导致的，基础类无法调用用户的代码。 为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。
第三次破坏：由于用户对程序的动态性的追求导致的，例如OSGi的出现。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构。
