JVM解毒——类加载子系统

时间 2020-02-23

标签 jvm 解毒加载子系统栏目 Java 繁體版

原文原文链接

带着问题，尤为是面试问题的学习才是最高效的。加油，奥利给！java

点赞+收藏就学会系列，文章收录在 GitHub JavaEgg ，N线互联网开发必备技能兵器谱git

直击面试

看你简历写得熟悉JVM，那你说说类的加载过程吧？
咱们能够自定义一个String类来使用吗？
什么是类加载器，类加载器有哪些？
多线程的状况下，类的加载为何不会出现重复加载的状况？
什么是双亲委派机制？它有啥优点？能够打破这种机制吗？

类加载子系统

类加载机制概念

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终造成能够被虚拟机直接使用的Java类型，这就是虚拟机的加载机制。Class文件由类装载器装载后，在JVM中将造成一份描述Class结构的元信息对象，经过该元信息对象能够获知Class的结构信息：如构造函数，属性和方法等，Java容许用户借由这个Class相关的元信息对象间接调用Class对象的功能,这里就是咱们常常能见到的Class类。github

类加载子系统做用

类加载子系统负责从文件系统或者网络中加载class文件，class文件在文件开头有特定的文件标识（0xCAFEBABE）
ClassLoader只负责class文件的加载。至于它是否能够运行，则由Execution Engine决定
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是class文件中常量池部分的内存映射）
Class对象是存放在堆区的

类加载器ClassLoader角色

class file存在于本地硬盘上，能够理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个如出一辙的实例
class file加载到JVM中，被称为DNA元数据模板，放在方法区
在.calss文件 -> JVM -> 最终成为元数据模板，此过程就要一个运输工具（类装载器），扮演一个快递员的角色

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。(验证、准备和解析又统称为链接，为了支持Java语言的运行时绑定，因此解析阶段也能够是在初始化以后进行的。以上顺序都只是说开始的顺序，实际过程当中是交叉的混合式进行的，加载过程当中可能就已经开始验证了)面试

1. 加载（Loading）：

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

加载 .calss 文件的方式数据库

从本地系统中直接加载
经过网络获取，典型场景：Web Applet
从zip压缩文件中读取，成为往后jar、war格式的基础
运行时计算生成，使用最多的是：动态代理技术
由其余文件生成，好比 JSP 应用
从专有数据库提取.class 文件，比较少见
从加密文件中获取，典型的防 Class 文件被反编译的保护措施

2. 链接（Linking）

验证（Verify）

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全bootstrap
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证api

准备（Prepare）

为类变量分配内存而且设置该类变量的默认初始值，即零值数组

数据类型	零值
int	0
long	0L
short	(short)0
char	'\u0000'
byte	(byte)0
boolean	false
float	0.0f
double	0.0d
reference	null

这里不包含用final修饰的static，由于final在编译的时候就会分配了，准备阶段会显示初始化tomcat

这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一块儿分配到Java堆中安全

private static int i = 1;  //变量i在准备阶只会被赋值为0，初始化时才会被赋值为1
private final static int j = 2;  //这里被final修饰的变量j，直接成为常量，编译时就会被分配为2
复制代码

解析（Resolve）

将常量池内的符号引用转换为直接引用的过程
事实上，解析操做每每会伴随着JVM在执行完初始化以后再执行
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明肯定义在《Java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
解析动做主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

3. 初始化（Initialization）

初始化阶段就是执行类构造器方法<clinit>()的过程
此方法不须要定义，是javac编译器自动收集类中的全部类变量的赋值动做和静态代码块中的语句合并而来
构造器方法中指令按语句在源文件中出现的顺序执行
<clinit>()不一样于类的构造器（构造器是虚拟机视角下的<init>()）
若该类具备父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

public class ClassInitTest{
  private static int num1 = 30;
  static{
    num1 = 10;
    num2 = 10;     //num2写在定义变量以前，为何不会报错呢？？
    System.out.println(num2);   //這裡直接打印能够吗？ 报错，非法的前向引用，能够赋值，但不可调用
  }
  private static int num2 = 20;  //num2在准备阶段就被设置了默认初始值0，初始化阶段又将10改成20
  public static void main(String[] args){
    System.out.println(num1);  //10
    System.out.println(num2);   //20
  }
}
复制代码

类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用。虚拟机规范规定有且只有5种状况必须当即对类进行“初始化”，即类的主动使用。

建立类的实例、访问某个类或接口的静态变量，或者对该静态变量赋值、调用类的静态方法（即遇到new、getstatic、putstatic、invokestatic这四条字节码指令时）
反射
初始化一个类的子类
Java虚拟机启动时被标明为启动类的类
JDK7 开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果，REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

除以上五种状况，其余使用Java类的方式被看做是对类的被动使用，都不会致使类的初始化。

eg:

public class NotInitialization {
    public static void main(String[] args) { 
        //只输出SupperClass int 123,不会输出SubClass init
        //对于静态字段，只有直接定义这个字段的类才会被初始化
        System.out.println(SubClass.value); 
    }
}

class SuperClass {
    static {
        System.out.println("SupperClass init");
    }
    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init");
    }
}
复制代码

类加载器

JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
从概念上来说，自定义类加载器通常指的是程序中由开发人员自定义的一类类加载器，可是Java虚拟机规范却没有这么定义，而是将全部派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

这个类加载使用C/C++ 语言实现，嵌套在JVM 内部
它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resource.jar或sun.boot.class.path路径下的内容），用于提供JVM自身须要的类
并不继承自 java.lang.ClassLoader，没有父加载器
加载扩展类和应用程序类加载器，并指定为他们的父类加载器
出于安全考虑，Boostrap 启动类加载器只加载名为java、Javax、sun等开头的类

扩展类加载器（Extension ClassLoader）

java语言编写，由sun.misc.Launcher$ExtClassLoader实现
派生于 ClassLoader
父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext 子目录（扩展目录）下加载类库。若是用户建立的JAR 放在此目录下，也会自动由扩展类加载器加载

应用程序类加载器（也叫系统类加载器，AppClassLoader）

java语言编写，由 sun.misc.Lanucher$AppClassLoader 实现
派生于 ClassLoader
父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path 指定路径下的类库
该类加载是程序中默认的类加载器，通常来讲，Java应用的类都是由它来完成加载的
经过 ClassLoader#getSystemClassLoader() 方法能够获取到该类加载器

public class ClassLoaderTest {
    public static void main(String[] args) {
        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //获取其上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);  //sun.misc.Launcher$ExtClassLoader@2503dbd3

        //再获取其上层：获取不到引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);     //null

        //对于用户自定义类来讲，默认使用系统类加载器进行加载，输出和systemClassLoader同样
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //String 类使用引导类加载器进行加载。Java的核心类库都使用引导类加载器进行加载，因此也获取不到
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);  //null

        //获取BootstrapClassLoader能够加载的api的路径
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }
    }
}
复制代码

用户自定义类加载器

在Java的平常应用程序开发中，类的加载几乎是由3种类加载器相互配合执行的，在必要时，咱们还能够自定义类加载器，来定制类的加载方式

为何要自定义类加载器？

隔离加载类
修改类加载的方式
扩展加载源（能够从数据库、云端等指定来源加载类）
防止源码泄露（Java代码容易被反编译，若是加密后，自定义加载器加载类的时候就能够先解密，再加载）

用户自定义加载器实现步骤

开发人员能够经过继承抽象类 java.lang.ClassLoader 类的方式，实现本身的类加载器，以知足一些特殊的需求
在JDK1.2以前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类，可是JDK1.2以后已经不建议用户去覆盖loadClass()方式，而是建议把自定义的类加载逻辑写在findClass()方法中
编写自定义类加载器时，若是没有太过于复杂的需求，能够直接继承URLClassLoader类，这样就能够避免本身去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁

ClassLoader经常使用方法

ClassLoader类，是一个抽象类，其后全部的类加载器都继承自ClassLoader（不包括启动类加载器）

方法	描述
getParent()	返回该类加载器的超类加载器
loadClass(String name)	加载名称为name的类，返回java.lang.Class类的实例
findClass(String name)	查找名称为name的类，返回java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回java.lang.Class类的实例
defineClass(String name, byte[] b, int off, int len)	把字节数组b中内容转换为一个Java类，返回java.lang.Class类的实例
resolveClass(Class<?> c)	链接指定的一个Java类

对类加载器的引用

JVM必须知道一个类型是由启动加载器加载的仍是由用户类加载器加载的。若是一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用做为类型信息的一部分保存在方法区中。当解析一个类型到另外一个类型的引用的时候，JVM须要保证这两个类型的类加载器是相同的。

双亲委派机制

Java虚拟机对class文件采用的是按需加载的方式，也就是说当须要使用该类的时候才会将它的class文件加载到内存生成class对象。并且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交给父类处理，它是一种任务委派模式。

工做过程

若是一个类加载器收到了类加载请求，它并不会本身先去加载，而是把这个请求委托给父类的加载器去执行；
若是父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
若是父类加载器能够完成类加载任务，就成功返回，假若父类加载器没法完成此加载任务，子加载器才会尝试本身去加载，这就是双亲委派模式

优点

避免类的重复加载，JVM中区分不一样类，不只仅是根据类名，相同的class文件被不一样的ClassLoader加载就属于两个不一样的类（好比，Java中的Object类，不管哪个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，若是不采用双亲委派模型，由各个类加载器本身去加载的话，系统中会存在多种不一样的Object类）
保护程序安全，防止核心API被随意篡改，避免用户本身编写的类动态替换 Java的一些核心类，好比咱们自定义类：java.lang.String

在JVM中表示两个class对象是否为同一个类存在两个必要条件：

类的完成类名必须一致，包括包名
加载这个类的ClassLoader（指ClassLoader实例对象）必须相同

沙箱安全机制

若是咱们自定义String类，可是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程当中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法就是由于加载的是rt.jar包中的String类。这样就能够保证对java核心源代码的保护，这就是简单的沙箱安全机制。

破坏双亲委派模型

双亲委派模型并非一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式，能够“被破坏”，只要咱们自定义类加载器，重写loadClass()方法，指定新的加载逻辑就破坏了，重写findClass()方法不会破坏双亲委派。
双亲委派模型有一个问题：顶层ClassLoader，没法加载底层ClassLoader的类。典型例子JNDI、JDBC，因此加入了线程上下文类加载器（Thread Context ClassLoader）,能够经过Thread.setContextClassLoaser()设置该类加载器，而后顶层ClassLoader再使用Thread.getContextClassLoader()得到底层的ClassLoader进行加载。
Tomcat中使用了自定ClassLoader，而且也破坏了双亲委托机制。每一个应用使用WebAppClassloader进行单独加载，他首先使用WebAppClassloader进行类加载，若是加载不了再委托父加载器去加载，这样能够保证每一个应用中的类不冲突。每一个tomcat中能够部署多个项目，每一个项目中存在不少相同的class文件（不少相同的jar包），他们加载到jvm中能够作到互不干扰。
利用破坏双亲委派来实现代码热替换（每次修改类文件，不须要重启服务）。由于一个Class只能被一个ClassLoader加载一次，不然会报java.lang.LinkageError。当咱们想要实现代码热部署时，能够每次都new一个自定义的ClassLoader来加载新的Class文件。JSP的实现动态修改就是使用此特性实现。

参考：《深刻理解JVM虚拟机》《尚硅谷JVM》