前言
在Java世界中，类加载机制是一个核心概念，而双亲委派机制更是类加载的基石。本文将深入剖析JVM的类加载过程、双亲委派机制的原理，并探讨如何破解这一机制，以及双亲委派机制下继承关系的处理方式。
作者：zhaokk
JVM的类加载过程与机制
在理解双亲委派机制之前，我们需要先了解JVM的类加载过程。JVM的类加载过程可以分为以下三个阶段：
- 加载（Loading）：在加载阶段，JVM会根据类的全限定名查找并加载类的字节码文件。这可以是从本地文件系统、网络等位置加载。加载后，类的字节码会存储在方法区（Metaspace）中。
- 连接（Linking）：连接阶段包括三个步骤，即验证、准备和解析。验证会确保字节码文件的合法性，准备会为类的静态变量分配内存并赋予默认值，解析会将符号引用替换为直接引用。
- 初始化（Initialization）：在初始化阶段，JVM会执行类的静态代码块和变量初始化操作。这是类加载的最后一步，也是在实际使用类之前执行的阶段。
双亲委派机制的原理
双亲委派机制是JVM类加载的基本策略，它的核心思想是：一个类加载器在加载类时，会首先委派给其父加载器加载。如果父加载器无法加载该类，子加载器才会尝试加载。这种机制建立了一个层次结构，保证类的加载是有序的。
双亲委派机制的优势在于避免了类的重复加载，确保类的一致性。比如，JDK自带的类会被Bootstrap ClassLoader加载，自定义的类会由Application ClassLoader加载。如果自定义的类与JDK自带类同名，双亲委派机制可以避免加载错误的类。
突破双亲委派机制
虽然双亲委派机制有助于保证类加载的一致性和安全性，但在某些情况下，我们可能希望突破这一机制。有一些场景需要我们自行加载类，而不受父加载器的限制。下面是一个简单的自定义类加载器示例：
代码语言：java复制public class CustomClassLoader extends ClassLoader {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
if (name.startsWith("com.example")) {
return loadCustomClass(name);
}
return super.loadClass(name);
}
private Class<?> loadCustomClass(String name) throws ClassNotFoundException {
try {
byte[] classData = loadClassData(name);
return defineClass(name, classData, 0, classData.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
private byte[] loadClassData(String name) throws IOException {
// Load class data from a custom source
// ...
}
}在这个示例中，我们继承了ClassLoader，并重写了loadClass方法。如果类名以"com.example"开头，我们会自行加载该类。否则，还是使用父加载器加载。
双亲委派机制下的类继承关系
在双亲委派机制下，类加载器之间的关系与继承关系有一定的联系。当一个类加载器尝试加载一个类时，它首先会委派给其父加载器。如果父加载器无法加载，子加载器才会尝试。这种关系反映在类的实际继承关系中：
- Bootstrap ClassLoader：这是最顶层的类加载器，负责加载JDK自带的类，如
java.lang.String。它没有父加载器。 - Extension ClassLoader：扩展类加载器加载JDK扩展目录中的类。
- Application ClassLoader：也称为系统类加载器，加载自定义的类。
这三者之间的继承关系正好与双亲委派机制相呼应。
结论
JVM的类加载机制和双亲委派机制是Java语言运行的基石。了解类加载过程、双亲委派机制的原理和应用，以及如何突破双亲委派机制，有助于我们更深入地理解Java的运行机制。同时，理解双亲委派机制下类加载器之间的继承关系，可以帮助我们更好地管理类的加载和解决冲突问题。
如果你有任何疑问或者观点，欢迎在评论区分享！
