关于后端:关于Java类加载问题我竟让面试官哑口无言

学习类加载之前咱们先看看从面试官的角度会问哪些问题？带着问题学习会更加高效。

看你简历写得相熟 JVM，那你说说类的加载过程吧？
咱们能够自定义一个 String 类来应用吗？
什么是类加载器，类加载器有哪些？这些类加载器都加载哪些文件？
多线程的状况下，类的加载为什么不会呈现反复加载的状况？
什么是双亲委派机制？它有啥劣势？能够突破这种机制吗？

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

类加载子系统负责从文件系统或者网络中加载 class 文件，class 文件在文件结尾有特定的文件标识（0xCAFEBABE）
ClassLoader 只负责 class 文件的加载。至于它是否能够运行，则由 Execution Engine 决定
加载的类信息寄存于一块称为办法区的内存空间。除了类的信息外，办法区中还寄存 - 运行时常量池信息，可能还包含字
Class 对象是寄存在堆区的

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

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包含：加载、验证、筹备、解析、初始化、应用和卸载七个阶段。(验证、筹备和解析又统称为连贯，为了反对 Java 语言的运行时绑定，所以解析阶段也能够是在初始化之后进行的。以上程序都只是说开始的程序，理论过程中是穿插的混合式进行的，加载过程中可能就曾经开始验证了)

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

加载 .class 文件的形式

从本地零碎中间接加载
通过网络获取，典型场景：Web Applet
从 zip 压缩文件中读取，成为日后 jar、war 格局的根底
运行时计算生成，应用最多的是：动静代理技术
由其余文件生成，比方 JSP 利用
从专有数据库提取 .class 文件，比拟少见
从加密文件中获取，典型的防 Class 文件被反编译的保护措施

2. 连贯（Linking）

验证（Verify）
目标在于确保 Class 文件的字节流中蕴含信息合乎以后虚拟机要求，保障被加载类的正确性，不会危害虚拟机本身平安
次要包含四种验证，文件格式验证，元数据验证，字节码验证，符号援用验证

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

数据类型 <img width=200/>	零值 <img width=200/>
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 在编译的时候就会调配了，筹备阶段会显示初始化
这里不会为实例变量调配初始化，类变量会调配在办法区中，而实例变量是会随着对象一起调配到 Java 堆中

private static int i = 1;  // 变量 i 在筹备阶只会被赋值为 0，初始化时才会被赋值为 1
private final static int j = 2;  // 这里被 final 润饰的变量 j，间接成为常量，编译时就会被调配为 2

将常量池内的符号援用转换为间接援用的过程
事实上，解析操作往往会随同着 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 类的形式被看作是对 类的被动应用 ，都不会 导致类的初始化。

例如:

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 的类加载器都划分为自定义类加载器

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

Java 语言编写，由 sun.misc.Launcher$ExtClassLoader 实现
派生于 ClassLoader
父类加载器为启动类加载器
从 java.ext.dirs 零碎属性所指定的目录中加载类库，或从 JDK 的装置目录的 jre/lib/ext 子目录（扩大目录）下加载类库。如果用户创立的 JAR 放在此目录下，也会主动由扩大类加载器加载

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 的实现动静批改就是应用此个性实现。

本文由 mdnice 多平台公布

关于后端:关于Java类加载问题我竟让面试官哑口无言

直击面试

类加载子系统

类加载机制概念

类加载子系统作用

类加载器 ClassLoader 角色

类加载过程

1. 加载（Loading）：

2. 连贯（Linking）

验证（Verify）

筹备（Prepare）

解析（Resolve）

3. 初始化（Initialization）

类的被动应用和被动应用

类加载器

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

扩大类加载器（Extension ClassLoader）

应用程序类加载器（也叫零碎类加载器，AppClassLoader）

用户自定义类加载器

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

对类加载器的援用

双亲委派机制

工作过程

劣势

沙箱平安机制

毁坏双亲委派模型

Just My Socks（注册教程内含优惠码）

关于后端:关于Java类加载问题我竟让面试官哑口无言

直击面试

类加载子系统

类加载机制概念

类加载子系统作用

类加载器 ClassLoader 角色

类加载过程

1. 加载（Loading）：

2. 连贯（Linking）

验证（Verify）

筹备（Prepare）

解析（Resolve）

3. 初始化（Initialization）

类的被动应用和被动应用

类加载器

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

扩大类加载器（Extension ClassLoader）

应用程序类加载器（也叫零碎类加载器，AppClassLoader）

用户自定义类加载器

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

对类加载器的援用

双亲委派机制

工作过程

劣势

沙箱平安机制

毁坏双亲委派模型

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）