JVM Class 类加载机制（系列号3）

类加载的过程

加载是类加载的一个阶段；虚拟机在运行时把描述类的信息的class文件数据加载进入内存，并对数据进行验证，准备，解析，初始化，使用与卸载七个阶段。

其中验证，准备，解析，三个阶段合起来称作为连接。类加载到初始化这一阶段结束。

加载：

加载期间，虚拟机执行三件事：通过全类名获得class文件的二进制流；将字节流的静态数据结构转化为运行时的数据结构；在内存中（经常在方法区）生成这个 java.lang.Class 对象（注意不是本类的对象，这正是反射里面讲的 Class 类的对象，在内存中唯一）。

加载或许还未完成，连接过程可能就已经开始了，但这两者的先后顺序是不变的。

验证：

确保class字节流包含的信息符合当前虚拟机的要求。包括文件格式验证，元数据验证，字节码验证，符号引用验证。

准备：

正式为类变量分配内存并设置类变量的初始值，这些类变量都将在方法区分配空间（类变量指的是用static修饰的，类级的变量，需要与实例变量区分）。另外这里说的初始值一般是0，false,null，不是Java语言中设定的初始值，实际值是在初始化阶段设置的。

解析：

解析阶段是虚拟机将class字节流中符号引用转化为直接引用的过程。

解析的具体内容：类或接口、字段、类方法、接口方法。

初始化：

这个初始化叫 <cinit>(类初始化，与<init>实例化不同)；而且父类初始化一定比子类初始化早。<cinit>是初始化类级变量的，<init>是初始化实例变量的。

• <cinit>会找到一切类级变量进行设置初始值，按照变量在类的代码顺序进行。这样的化，在前面的静态变量肯定无法访问位于其后的静态变量的值。
• 如果没有类级变量，那么<cinit>不是必须的。
• 接口中不能使用静态语句块，接口中只能包含除抽象方法之外的常量，所以也会有<cinit>,但是接口与类不同的是，接口执行<init>不需要先执行父接口的<init>

 

什么情况下进行初始化

• 遇到 new getstatic putstatic invokesataic :即使用 new 进行实例化之前类必须进行初始化（注意区分类的初始化，和类的实例化）的时候，读取或设置一个类的静态字段（被final修饰在编译器已经放入常量池的除外），以及调用一个类的静态方法的时候，必须先初始化。
• Java 进行反射调用的时候
• 初始化一个类之前，需要先初始化其父类
• 虚拟机启动时用户指定的主类需要进行初始化
• 还有一种情况现在保密

注意除了以上的五种情况，其余关于类的引用都属于被动引用，不会对类进行初始化，比如：

1. 通过子类引用父类的静态字段，Sub.value 只会初始化父类，因为访问静态字段，只会初始化定义这个静态字段的类。
2. new 对象数组 ，数组指定的类型不会 进行类的初始化。Object [ ]  O = new Object [10] 。
3. 常量在编译的时候就会存放到调用类的常量池中，所以调用常量，不会初始化常量所在的类。

输出OKJD;

类与类加载器：

对于任意的一个类，都需要类和类加载器共同去确定虚拟机中类的唯一性。如果类加载器不一样，会在equals,isInstance,instanceof的方法上产生影响。

但是从Java虚拟机的角度来说，一种是启动类加载器（C++编写），一种是其他加载器（独立于虚拟机，由Java语言实现）；

总之就是三个：

• 启动类加载器
• 扩展类加载器
• 应用程序类加载器

双亲委派模式工作原理

（引用：https://blog.youkuaiyun.com/javazejian/article/details/73413292）

双亲委派模式要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，请注意双亲委派模式中的父子关系并非通常所说的类继承关系，而是采用组合关系来复用父类加载器的相关代码，类加载器间的关系如下：

其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己想办法去完成，这不就是传说中的实力坑爹啊？那么采用这种模式有啥用呢?
 

双亲委派模式优势

采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。可能你会想，如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢？该类并不存在java.lang中，经过双亲委托模式，传递到启动类加载器中，由于父类加载器路径下并没有该类，所以不会加载，将反向委托给子类加载器加载，最终会通过系统类加载器加载该类。但是这样做是不允许，因为java.lang是核心API包，需要访问权限，强制加载将会报出异常。