【jvm类加载机制】深度剖析jvm类加载机制-爱代码爱编程
深度剖析JVM类加载机制
前言
本篇文章主要讲述了JVM类加载机制的过程，包括类加载器、双亲委派机制两个方面，结合了相关源码进行阐述，通过阅读本篇文章可以让你对JVM类加载机制有全新的理解，更好的学习JVM。希望本篇文章对你有所帮助。如果在阅读本篇文章有什么独到的见解或者问题，可以留言或者私信，进行探讨。希望各位点赞加关注，让我创作出更多的文章，后续对于JVM的文章也会持续更新，对jvm有兴趣的也可以订阅专栏。
类加载运行全过程
当我们用java命令运行某个类的main函数启动程序时，首先需要通过类加载器把主类加载到 JVM。
public class Math {
public static final int DATA = 666;
public static User user = new User();
public int compute() {
int a = 1;
int b = 2;
int c = (a + b) * 2;
return c;
}
public static void main(String[] args) {
Math math = new Math();
math.compute();
}
}
当我们运行main方法时，类加载的全流程如下：
这里主要关注两个地方：一个是loadClass(),这里完成了类的加载;一个是sun.misc.Launcher.getLauncher()，这里完成了类加载器的创建;
loadClass的类加载过程
加载->验证->准备->解析->初始化->使用->卸载
-
加载：在硬盘上查找并通过IO读入字节码文件，使用到类的时候才会进行加载，例如调用类的mian方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
-
类被加载到方法区中后主要包含，运行时常量池、类型信息、字段信息、方法信息、类加载器的引用和对应class实例的引用等信息。
-
类加载器的引用：这个类到类加载器实例的引用
-
对应class实例的引用：类加载器在加载类的信息放到方法区中后，会创建一个对应的Class类型的对象实例放到堆中，作为开发人员访问方法区中类定义的入口和切入点
-
-
-
验证：校验字节码文件(.class)的正确性（文件格式）
-
准备：给类的静态变量分配内存，并赋予默认值
注意：这里是给静态变量分配内存，而不是所有的变量，并且是赋予默认值，具体的赋值在初始化阶段。
-
解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如mian方法)替换为指向数据所存内存的指针或者句柄等(直接引用)，这也就是静态链接的过程(在类加载期间完成)，而动态链接是在程序运行期间完成的将符号引用替换为直接引用。
**静态链接和动态链接的区别：**对象不同：静态链接针对的就是静态方法，动态链接针对的就是非静态方法；时期不同：静态链接是在类加载期间完成，动态链接是在程序运行期间完成。
-
初始化：对类的静态变量初始化为指定的值，执行静态代码块(static{}包裹的就是静态代码块)。
**注意：**主类在运行过程中如果用到其他类，会逐步加载这些类。
jar包或者war包里的类不是一次性全部加载的，是使用到时才加载，也就是懒加载。
类加载器和双亲委派机制
类加载器的类型
上面的类加载过程主要是通过类加载器来实现的，java里面的类加载器主要有以下几种：
- 引导类加载器： 负责加载支撑JVM运行的位于JRE的lib目录下的核心类库。(C++实现)
- 扩展类加载器： 负责加载支撑JVM运行的位于JRE的lib目录下的ext拓展目录中的JAR包。
- 应用程序类加载器： 负责加载ClassPath路径下的类包，也就是自己写的类。
- 自定义加载器： 负责加载用户自定义路径下的类包。
类加载器的初始化过程
通过类运行加载的群过程流程图可知，其中会创建JVM实例sun.misc.Launcher。
sun.misc.Launcher初始化使用了单例模式设计，保证了一个JVM虚拟机内只有一个sun.misc.Launcher实例。
在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)，JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
public Launcher() {
// Create the extension class loader
ClassLoader extcl;
try {
extcl = ExtClassLoader.getExtClassLoader();
} catch (IOException e) {
throw new InternalError(
"Could not create extension class loader", e);
}
// Now create the class loader to use to launch the application
try {
loader = AppClassLoader.getAppClassLoader(extcl);
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}
public ClassLoader getClassLoader() {
return loader;
}
}
双亲委派机制
在Launcher构造方法创建了两个类加载器（扩展类加载器、应用程序类加载器）会自动建立亲子结构，也就形成了双亲委派机制。
这里的类加载其实就是一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有的父类加载器在自己的加载类路径上都找不到目标类，则在自己的类加载路径上查找并载入目标类。
比如我们的例子Math类，最先会找到应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展器类加载器再委托引导类加载器，引导类加载器找不到会向下退回加载Math类的请求，扩展类加载器收到请求后，就会自己加载，假如自己也加载不到，就会向下退回加载Math类的请求到应用程序类加载器，应用程序类加载器就会自己加载。
注意：这里的子类跟父类不是继承里面的子类和父类，类加载器之间没有继承关系，只是类加载器的parent属性值是父类加载器。
双亲委派机制就是，先找父类加载器加载，不行由儿子自己加载。
从源码可以看出，子类先交给父类加载，父类加载不了再自己加载
public Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
int i = name.lastIndexOf('.');
if (i != -1) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPackageAccess(name.substring(0, i));
}
}
if (ucp.knownToNotExist(name)) {
// The class of the given name is not found in the parent
// class loader as well as its local URLClassPath.
// Check if this class has already been defined dynamically;
// if so, return the loaded class; otherwise, skip the parent
// delegation and findClass.
Class<?> c = findLoadedClass(name);
if (c != null) {
if (resolve) {
resolveClass(c);
}
return c;
}
throw new ClassNotFoundException(name);
}
return (super.loadClass(name, resolve));
//双亲委托机制代码实现（代码的校验进行了删减，只提取了有用的部分）
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
//首先判断自己加载过的集合里面有没有该类
Class<?> c = findLoadedClass(name);
if (c == null) {
//自己加载过的集合里面没有该类
long t0 = System.nanoTime();
if (parent != null) {
//父类不为空，则继续找父类加载
c = parent.loadClass(name, false);
} else {
//父类为空，此时到了引导类加载器，没找到就返回null，
c = findBootstrapClassOrNull(name);
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//进行类加载
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
//自己加载过的集合里面有该类，直接返回
return c;
}
}
为什么要设置双亲委派机制？
-
沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改。
-
避免类的重复加载：当父亲已经加载了该类时，就没有必要让子类的类加载器再加载一次，保证被加载类的唯一性。
全盘负责委托机制
"全盘负责"是指当一个ClassLoader装载一个类时，除非显示的使用另外一个ClassLoader，该类所依赖以及引用的类也由这个ClassLoader载入。
就是在加载一个类的时候，加载该类的加载器会加载该类以及该类所依赖的类。
自定义类加载器实例
自定义类加载器只需要继承java.lang.ClassLoader类，该类有两个核心方法，一个是loadClass(String，boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。
public class MyClassLoaderTest {
static class MyClassLoader extends ClassLoader {
private String classPath;
public MyClassLoader(String classPath){
this.classPath = classPath;
}
//将类文件读取到字节数组中
private byte[] loadByte(String name) throws Exception {
name = name.replace("\\.","/");
FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
//重写findClass方法
//作用：根据传过来的类名，在磁盘上找对应的类，通过defineClass方法调用本地方法实现类加载
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
return defineClass(name,data,0, data.length);
} catch (Exception e) {
throw new ClassNotFoundException();
}
}
}
public static void main(String args[]) throws Exception {
//初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父类加载器设置为应用程序类加载器
MyClassLoader classLoader = new MyClassLoader("D:/test");
//文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
//这里利用了反射调用了User1类的sout方法
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj,null);
//输出User1类加载器
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
打破双亲委派机制
想要自定义类加载器去加载类，而不是委托父类加载器去加载
实现双亲委派机制的关键在于loadClass，只需要重写loadClass就可以打破双亲委派机制。重写也只需要将ClassLoader的loadClass方法里的try-catch部分删去就可以。**但是这样修改，假如需要加载的类依赖核心核心类，由于全盘负责委托机制，当前类加载器还需要加载核心类，但是找不到核心类，就会出现报错，由于有沙箱安全机制，所以不能直接将依赖的核心类通过复制来解决问题。**此时就需要对加载的类进行判断（改进代码在// 之间//），整体代码如下：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
long t1 = System.nanoTime();
//
if(!name.startsWith("com.ez.jvm")) {
c = this.getParent().loadClass(name);
} else {
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;
}
}
Tomcat打破双亲委派机制
思考，Tomcat如果使用默认的双亲委派类加载机制行不行？
解决这个问题的思路，首先我们要弄懂Tomcat需要解决什么问题
- 不同程序第三方库版本问题。Tomcat是一个web容器，作为一个容器，可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方库的不同版本，因此要保证每一个应用程序的类库都是独立的，相互隔离的。
- 相同程序相同类库共享问题。部署在同一个容器里面的相同类库的相同版本可以共享。防止类库重复加载。
- 容器类库与程序类库隔离问题。web容器也有自己依赖的类库，不能和程序的类库相混淆。基于安全考虑，应该让容器类库与程序类库相隔离。
- **jsp修改后不用重启问题。**web容器要支持jsp修改，jsp文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后可能经常性修改jsp，因此web容器需要支持jsp修改后不需要重启。
进而回答我们的问题。Tomcat如果使用默认的双亲委派类加载机制行不行？
相信在了解了双亲委派机制和Tomcat需要解决的问题，这个题目的答案是不行的，针对上面的问题，来看看默认的类加载机制能否满足要求。
- 如果使用默认的类加载机制，那么是无法加载两个相同类库的不同版本的，默认的类加载器不管你是什么版本，只在乎你的全限定名，并只有一份。因此第一、三问题不能解决。
- 默认的类加载器是能够实现相同程序相同类库共享问题，因为它的职责就是保证唯一性。
- 怎样实现jsp的热加载呢？jsp文件实际上也就是class文件，虽然内容修改了，但是类名是一样的，类加载器会直接从方法去中存在的进行加载，修改后的jsp是不会重新加载的。每个jsp文件会对应一个唯一的类加载器，当一个jsp文件被修改，我们只需要重新创建类加载器，就能实现jsp的热加载了。
那么下一个问题，Tomcat是怎么打破双亲委派机制的呢？
tomcat为了实现隔离性，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制
Tomcat自定义加载器详解
Tomcat类加载机制流程图
tomcat的主要类加载器
- commonClassLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
- catalinaClassLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
- sharedClassLoader：各个Webapp共享的类加载器，加载路径中的class对于所有的Webapp可见，但对于Tomcat容器不可见；解决了容器类库与程序类库隔离问题。
- WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；比如加载war包里的相关类，每个war包应用都有自己的WebappClassLoader，实现相互隔离。也就解决了不同程序第三方库版本问题。
实现Tomcat自定义加载器
其实在学习打破双亲委派机制时的代码，就已经差不多实现了Tomcat自定义加载器，只需要把对于不同的war包生成不同的类加载实例即可。
public class MyClassLoaderTest {
static class MyClassLoader extends ClassLoader {
private String classPath;
public MyClassLoader(String classPath){
this.classPath = classPath;
}
//将类文件读取到字节数组中
private byte[] loadByte(String name) throws Exception {
name = name.replace("\\.","/");
FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
//重写findClass方法
//作用：根据传过来的类名，在磁盘上找对应的类，通过defineClass方法调用本地方法实现类加载
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
return defineClass(name,data,0, data.length);
} catch (Exception e) {
throw new ClassNotFoundException();
}
}
//重写loadClass方法
//作用：打破双亲委派机制
@Override
protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
long t1 = System.nanoTime();
//
if(!name.startsWith("com.ez.jvm")) {
c = this.getParent().loadClass(name);
} else {
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;
}
}
}
public static void main(String args[]) throws Exception {
//初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父类加载器设置为应用程序类加载器
MyClassLoader classLoader = new MyClassLoader("D:/test");
//文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
//这里利用了反射调用了User1类的sout方法
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj,null);
//输出User1类加载器
System.out.println(clazz.getClassLoader().getClass().getName());
//再new一个类加载实例即可
MyClassLoader classLoader = new MyClassLoader("D:/test");
//文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
//这里利用了反射调用了User1类的sout方法
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj,null);
//输出User1类加载器
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
这里的代码只是简单的实现了下Tomcat类加载的原理，真实情况肯定不会那么简单，比如对于jsp的热加载，肯定会用到线程、定时任务等等，启动一个线程对文件改动进行监听，改动了就修改jsp类加载器，在这里就不多赘述。
/这里利用了反射调用了User1类的sout方法
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj,null);
//输出User1类加载器
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
这里的代码只是简单的实现了下Tomcat类加载的原理，真实情况肯定不会那么简单，比如对于jsp的热加载，肯定会用到线程、定时任务等等，启动一个线程对文件改动进行监听，改动了就修改jsp类加载器，在这里就不多赘述。