java类加载机制
类是java编程语言的基本单元。java的源代码经过编译后生成java的字节码文件（class文件），字节码文件是以二进制的形式存储。在运行时，这些类的字节码文件会加载进入JVM的内存的元空间中，并且以Class<T>的形式对类进行描述。本文将详细讲解java的类加载机制。
类加载流程
加载：通过
classloader将字节码文件以二进制字节流的形式读入到内存中，将字节流转换为方法区运行时的数据结构，在内存中生成一个Class<T>对象对类进行描述。链接：验证阶段检查字节码文件是否符合JVM规范，准备阶段为类中的静态字段分配内存并赋予初始值，解析阶段将虚拟机中常量池中的符号引用转化为直接引用。符号引用存在于编译生成的字节码中，用来描述当前类对其他类的引用。直接引用是可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。解析阶段也可以在运行过程中发生，这个跟动态语言调用相关。
- 初始化：初始化是类加载的最后一步，前面的类加载的过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的java程序代码。它主要是负责：初始化阶段是执行类构造器（静态代码块）
< clinit >()方法的过程，< clinit >()是编译器自动收集类中所有的类变量的赋值动作、静态代码块产生的。
ClassLoader
ClassLoader顾名思义是类的加载器，类的加载要通过ClassLoader进行，ClassLoader的职责是将字节码文件从磁盘或者网络中加载进JVM内存。同时你也可以在java代码中操作ClassLoader定义一些自定义的行为。ClassLoader是一个抽象基类，你可以继承它重写自己自定义的加载流程。一般我们的java类会通过几个常见的类加载器加载，它们分为BootstrapClassLoader，ExtensionClassLoader，ApplicaitonClassLoader。
BootstrapClassLoader主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中，注意必由于虚拟机是按照文件名识别加载jar包的，如rt.jar，如果文件名不被虚拟机识别，即使把jar包丢到lib目录下也是没有作用的(出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。
ExtensionClassLoader是指Sun公司(已被Oracle收购)实sun.misc.Launcher$ExtClassLoader类，由Java语言实现的，是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用标准扩展类加载器。
ApplicationClassLoader也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。
双亲委派机制
双亲委派机制是指，当一个ClassLoader尝试加载一个类时，它并不会自己加载，而是将加载任务向上委托给父加载器加载。每个ClassLoader中都有一个parent属性，用来保存父加载器的引用。注意：父加载器并不是父类加载器，它们之间没有类之间的继承关系。双亲委派机制的加载流程为：在类加载器缓存中查询，此类是否已经加载，若已加载，则直接由此加载器加载，若没有则向上委托给父加载器加载。若最上层父加载器也未加载，则向下委托给子加载器加载。
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先检查类是否已经加载过
Class<?> c = findLoadedClass(name);
if (c == null) {
// 没有加载过，则委托父加载器加载
long t0 = System.nanoTime();
try {
if (parent != null) {
// 若有父加载器，则委托父加载加载
c = parent.loadClass(name, false);
} else {
// 若没有父加载器（最上层父加载器也未加载此类），则委托BootStrap加载器加载
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
// 这种情况代表Bootstrap加载器也未加载此类，则委托给本加载器加载。
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
PerfCounter.getParentDelegationTime().addTime(t1 - t0);
PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
测试双亲委派机制
-
新建一个测试用的类
package misc; public class Model { static { System.out.println("类被加载了"); } public static void sayHello() { System.out.println("hello"); } } -
自己定义一个类加载器
public class MyClassLoader extends ClassLoader { private final String classPath; public MyClassLoader(String classPath) { this.classPath = classPath; } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { // 如果使用MyClassLoader加载，那么这句话将会输出至控制台 System.out.println("使用MyClassLoader加载"); var classFilePath = classPath + "/" + name.replace(".","/").concat(".class"); var bao = new ByteArrayOutputStream(); var readByte = 1; try { var fis = new FileInputStream(classFilePath); while ((readByte = fis.read()) != -1) { bao.write(readByte); } var bytesArray = bao.toByteArray(); return defineClass(name, bytesArray, 0, bytesArray.length); } catch (IOException ex) { ex.printStackTrace(); throw new ClassNotFoundException(ex.getMessage()); } } } -
测试代码
public static void loadClassViaMyClassLoader() throws Exception { var classLoader = new MyClassLoader("/Users/huobingnan/code/java/misc/out/production/misc"); var modelClass = classLoader.loadClass("misc.Model"); System.out.println("Model的类加载器是：" + modelClass.getClassLoader()); var sayHelloMethod = modelClass.getDeclaredMethod("sayHello"); sayHelloMethod.invoke(null); } -
测试输出
Model的类加载器是：jdk.internal.loader.ClassLoaders$AppClassLoader@7c53a9eb 类被加载了 hello通过输出可以发现，Model类的加载并未使用我们自定义的
MyClassLoader，而是使用了JDK中的应用程序类加载器，这就是双亲委派机制的体现，你也可以对上述代码进行DEBUG运行，从中便可得知类加载的途径是MyClassLoader -> AppClassLoader -> PlatformClassLoader -> BootstrapClassLoader -> PlatformClassLoader -> AppClassLoader。注意：不同的JDK可能加载器的名称会有所不同，笔者这里使用的是zulu-jdk-arm64。
打破双亲委派机制
通过上文的测试用例可以得知，尽管我们自定义了ClassLoader，但是由于双亲委派机制的存在，字节码文件没有使用我们自定义的ClassLoader加载。那么如何强制字节码文件使特定ClassLoader加载呢？我们可以通过重写CLassLoader.loadClass(String name, boolean resovle)方法进行。例如下面的代码：
public class MyClassLoader extends ClassLoader
{
private final String classPath;
public MyClassLoader(String classPath)
{
this.classPath = classPath;
}
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
if (name.startsWith("misc"))
{
// 如果包名以misc开头，我们使用MyClassLoader加载
return findClass(name);
}
return super.loadClass(name, resolve);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException
{
System.out.println("使用MyClassLoader加载");
var classFilePath = classPath + "/" + name.replace(".", "/").concat(".class");
var bao = new ByteArrayOutputStream();
var readByte = 1;
try
{
var fis = new FileInputStream(classFilePath);
while ((readByte = fis.read()) != -1)
{
bao.write(readByte);
}
var bytesArray = bao.toByteArray();
return defineClass(name, bytesArray, 0, bytesArray.length);
} catch (IOException ex)
{
ex.printStackTrace();
throw new ClassNotFoundException(ex.getMessage());
}
}
}
更改之后，再次使用上文中的测试代码进行测试：
使用MyClassLoader加载
Model的类加载器是：misc.MyClassLoader@d041cf
类被加载了
hello
这里可以看到，通过重写loadClass方法，我们可以自定义类加载行为，打破双亲委派机制。
打破双亲委派机制带来的问题
虽然我们自定义了类加载，并且打破了双亲委派机制，使得我们可以自定义类加载器加载类的行为。但是打破双亲委派机制后会带一个问题：
public static void testClassLoaderCastBehavior() throws Exception
{
var classLoader = new MyClassLoader("/Users/huobingnan/code/java/misc/lib");
var modelClass = classLoader.loadClass("misc.Model");
var object = modelClass.getConstructor().newInstance();
var model = (Model)object;
}
使用MyClassLoader加载
类被加载了
Exception in thread "main" java.lang.ClassCastException: class misc.Model cannot be cast to class misc.Model (misc.Model is in unnamed module of loader misc.MyClassLoader @d041cf; misc.Model is in unnamed module of loader 'app')
at misc.ClassLoaderTest.testClassLoaderCastBehavior(ClassLoaderTest.java:19)
at misc.ClassLoaderTest.main(ClassLoaderTest.java:85)
使用自定义类加载器，在文件系统中加载了一个类，这个类与我们项目类路径中的Model类定义完全一致，但是他们之间并不能进行强制类型转换。这也就是说，虽然我们可以加载这个类，但是在使用的时候只能通过反射的方式进行。我们知道通过反射对一个类进行操作会带来隐患，而且对于用户来说，这样的调用操作并不直观。
同时，这种行为也限制了我们在项目中保留接口定义的情况下，无法通过类加载器的加载实现类并强制转换使用。
如果想要通过接口的形式进行上述操作需要借助java的SPI机制。
参考文献
- 张善香. 解析Java虚拟机开发：权衡优化，高效和安全的最优方案[M]. 北京: 清华大学出版社: 2013.
- java类加载机制（全套）https://juejin.cn/post/6844903564804882445
- Java SPI机制 https://zhuanlan.zhihu.com/p/28909673
