# 前言通过上一篇 [# 探究类加载过程 | Java是如何做到一次编译到处运行的？](https://juejin.cn/post/7267800436260864041) 学习了类的加载过程的几个重要阶段，以及了解了Java是如何做到一次编译到处运行的。其实，关于类加载，还有两个非常重要的内容，就是类加载器和双亲委派机制，也是面试时常见考核问题。 # 一、类加载器还是以这个简单的代码为例： ``` package com.jvm.test; public class Book { public static void main(String[] args) { String name = "《三体》"; System.out.printf("一本你不看，都不知道何为“惊艳”二字的书：" + name); } } ``` 上面的类的加载是要通过类加载器来实现的。
Java中有几种类加载器： - **引导类加载器(BootstrapClassLoader）**: 这是JVM的内置类加载器，负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等，即对应如`java.lang`包中的类等。
它是所有其他类加载器的父加载器，是类加载器层次结构的顶层，由JVM本身实现，由C++实现。
需要注意的是：这里的“父”，不是我们Java中的类继承的父类，这里的“父加载器”可以理解是逻辑上的概念，更多是指加载器之间的协作机制。 - **扩展类加载器（`ExtClassLoader`）：**：这个类加载器负责加载Java的扩展类库，位于`/lib/ext`目录下的JAR文件。
他的父加载器是引导类加载器，通过扩展类加载器，可以实现对JVM的扩展功能。 - **应用程序类加载器（AppClassLoader）**：也被称为系统类加载器，它负责加载应用程序的类，也就是我们自己编写的Java代码的加载器。
它的父加载器是扩展类加载器。 - **自定义类加载器（CustomClassLoader）**：除了上述的三种主要的类加载器，Java还提供自定义类加载器的能力，允许开发人员根据需求实现自己的类加载逻辑。
负责加载用户自定义路径下的类包。了解了这几种不同的加载器，如我们上述实例的代码的类的加载，应该也很容易得知是由 **应用程序类加载器** 来加载。接下来看一个**类加载器**的示例： ``` package com.jvm.classloader; import sun.misc.Launcher; import java.net.URL; public class TestJDKClassLoader { public static void main(String[] args) { System.out.println(String.class.getClassLoader()); System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName()); System.out.println(TestJDKClassLoader.class.getClassLoader().getClass().getName()); System.out.println(); ClassLoader appClassLoader = ClassLoader.getSystemClassLoader(); ClassLoader extClassloader = appClassLoader.getParent(); ClassLoader bootstrapLoader = extClassloader.getParent(); System.out.println("the appClassLoader : " + appClassLoader); System.out.println("the extClassloader : " + extClassloader); System.out.println("the bootstrapLoader : " + bootstrapLoader); System.out.println(); System.out.println("bootstrapLoader加载以下路径文件："); URL[] urls = Launcher.getBootstrapClassPath().getURLs(); for (int i = 0; i < urls.length; i++) { System.out.println(urls[i]); } System.out.println(); System.out.println("extClassloader加载以下路径文件："); System.out.println(System.getProperty("java.ext.dirs")); System.out.println(); System.out.println("appClassLoader加载以下路径文件："); System.out.println(System.getProperty("java.class.path")); } } ``` 可以思考一下输出结果是啥？
输出结果： ``` null sun.misc.Launcher$ExtClassLoader sun.misc.Launcher$AppClassLoader the appClassLoader : sun.misc.Launcher$AppClassLoader@18b4aac2 the extClassloader : sun.misc.Launcher$ExtClassLoader@6ce253f1 the bootstrapLoader : null bootstrapLoader加载以下路径文件： file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/resources.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/rt.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/sunrsasign.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jsse.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jce.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/charsets.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jfr.jar file:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/classes extClassloader加载以下路径文件： /Users/lan/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java appClassLoader加载以下路径文件： /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/tools.jar:/Users/lan/lihy/study/tuling/jvm/jvm-full-gc/target/classes:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-starter-web/2.1.2.RELEASE/spring-boot-starter-web-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-starter/2.1.2.RELEASE/spring-boot-starter-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot/2.1.2.RELEASE/spring-boot-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-autoconfigure/2.1.2.RELEASE/spring-boot-autoconfigure-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-starter-logging/2.1.2.RELEASE/spring-boot-starter-logging-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar:/Users/lan/.m2/repository/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar:/Users/lan/.m2/repository/org/apache/logging/log4j/log4j-to-slf4j/2.11.1/log4j-to-slf4j-2.11.1.jar:/Users/lan/.m2/repository/org/apache/logging/log4j/log4j-api/2.11.1/log4j-api-2.11.1.jar:/Users/lan/.m2/repository/org/slf4j/jul-to-slf4j/1.7.25/jul-to-slf4j-1.7.25.jar:/Users/lan/.m2/repository/javax/annotation/javax.annotation-api/1.3.2/javax.annotation-api-1.3.2.jar:/Users/lan/.m2/repository/org/yaml/snakeyaml/1.23/snakeyaml-1.23.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-starter-json/2.1.2.RELEASE/spring-boot-starter-json-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.9.8/jackson-databind-2.9.8.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.9.0/jackson-annotations-2.9.0.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.9.8/jackson-core-2.9.8.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jdk8/2.9.8/jackson-datatype-jdk8-2.9.8.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.9.8/jackson-datatype-jsr310-2.9.8.jar:/Users/lan/.m2/repository/com/fasterxml/jackson/module/jackson-module-parameter-names/2.9.8/jackson-module-parameter-names-2.9.8.jar:/Users/lan/.m2/repository/org/springframework/boot/spring-boot-starter-tomcat/2.1.2.RELEASE/spring-boot-starter-tomcat-2.1.2.RELEASE.jar:/Users/lan/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/9.0.14/tomcat-embed-core-9.0.14.jar:/Users/lan/.m2/repository/org/apache/tomcat/embed/tomcat-embed-el/9.0.14/tomcat-embed-el-9.0.14.jar:/Users/lan/.m2/repository/org/apache/tomcat/embed/tomcat-embed-websocket/9.0.14/tomcat-embed-websocket-9.0.14.jar:/Users/lan/.m2/repository/org/hibernate/validator/hibernate-validator/6.0.14.Final/hibernate-validator-6.0.14.Final.jar:/Users/lan/.m2/repository/javax/validation/validation-api/2.0.1.Final/validation-api-2.0.1.Final.jar:/Users/lan/.m2/repository/org/jboss/logging/jboss-logging/3.3.2.Final/jboss-logging-3.3.2.Final.jar:/Users/lan/.m2/repository/com/fasterxml/classmate/1.4.0/classmate-1.4.0.jar:/Users/lan/.m2/repository/org/springframework/spring-web/5.1.4.RELEASE/spring-web-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-beans/5.1.4.RELEASE/spring-beans-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-webmvc/5.1.4.RELEASE/spring-webmvc-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-aop/5.1.4.RELEASE/spring-aop-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-context/5.1.4.RELEASE/spring-context-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-expression/5.1.4.RELEASE/spring-expression-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar:/Users/lan/.m2/repository/org/springframework/spring-core/5.1.4.RELEASE/spring-core-5.1.4.RELEASE.jar:/Users/lan/.m2/repository/org/springframework/spring-jcl/5.1.4.RELEASE/spring-jcl-5.1.4.RELEASE.jar:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar Process finished with exit code 0 ``` 通过前面对几种类加载的了解，对这个输出结果应该问题不大。
但是可能有几个小疑问：
1、 `System.out.println(String.class.getClassLoader());`这个语句，为何输出时`null`?
因为`System`类是Java核心类库中的类，它是由引导类加载器加载。引导类加载器是JVM的内置加载器，由C++实现，因此在Java中就输出为`null`。
2、`System.out.println("the bootstrapLoader : " + bootstrapLoader);`为何也输出为`null`? 这里`extClassloader.getParent()`获取扩展类加载器的父加载器，即引导类加载器，其由C++实现，因此在Java中就输出也就为`null`。 **类加载初始化过程** ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc2fa2590b124fa3b7720486ca8258c9~tplv-k3u1fbpfcp-watermark.image?) 如上类运行加载全过程图，可知在JVM启动的过程中，会有一系列的初始化操作，包括创建类加载器、加载核心类库等。在这个初始化的过程，C++（其实是JVM自身调用，因为JVM底层是C++实现，从底层的角度，就是C++代码调用Java）调用Java`sun.misc.Launcher`类的构造方法 `Launcher()`创建实例。
在`Launcher`构造方法的内部，会创建两个类加载器：
- sun.misc.Launcher.ExtClassLoader（扩展类加载器） - sun.misc.Launcher.AppClassLoader（应用程序加载器） **Launcher构造器核心源码**：
![carbon (1).png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f04d0b5723534d2fbfcdc28ad5968c25~tplv-k3u1fbpfcp-watermark.image?) JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。 # 二、什么是双亲委派？ > 双亲委派是一种类加载的机制。如果一个类加载器接到加载类的请求时，它首先不会自己尝试加载这个类，而是把这个请求任务委托给其父加载器去完成，依次递归，如果父加载器可以完成类加载任务，就成功返回。只有父加载器无法完成此加载任务时，才自己去加载。 JVM类加载器的层级结构图： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9e71c1bc05ae4be3bf9f5435408a5e83~tplv-k3u1fbpfcp-watermark.image?) 我们直接先来看一下应用程序类加载器（`AppClassLoader`）加载类的双亲委派机制源码，`AppClassLoader`的`loadClass`方法最终会调用其父类`ClassLoader`的`loadClass`方法, 该方法核心源码： ![carbon.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/89748eaf04b14ec391168269370718ee~tplv-k3u1fbpfcp-watermark.image?) 该方法的大体逻辑为：
1. 首选，会检查自己加载器缓存，查看自己是否已经加载过目标类，如果已经加载过，直接返回。 2. 如果此类没有被加载过，则判断一下是否有父加载器；如果有父加载器，则由父加载器（即` 调用c = parent.loadClass(name, false);`），如果没有父加载器则调用bootstrap类加载器来加载。 3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前的类加载器的findClass方法（即`c = findClass(name);`）来完成类加载。 **双亲委派机制简单点说就是：先找父亲加载，不行再由儿子自己加载。** # 三、为什么要设计双亲委派机制？ - **沙箱安全机制**：核心类库由引导类加载器（Bootstrap ClassLoader）加载，防止恶意类替代核心类。不同类加载器加载的类相互隔离，防止类之间的冲突。例如自己写的java.lang.String类是不会被加载的。 - **保证类的唯一性：** 双亲委派机制确保在JVM中同一个类只会被加载一次，避免了类的重复加载，保证了类的唯一性。 - **保证类的一致性：** 类加载器的层次结构保证了类的一致性。当一个类加载器需要加载一个类时，它首先会委派给其父加载器去尝试加载。如果父加载器无法加载该类，子加载器才会尝试加载。这种委派链式查找保证了类的一致性。如果你对唯一性和一致性有些混淆，那我们可以借助以下的例子进行帮助理解：
唯一性：就像每个人的身份证号码都是独一无二的。在类加载机制中，就像每个类在Java中都有唯一的类加载器来加载，保证不同的类拥有不同的加载器，避免了类之间的冲突和混淆。一致性：无论在什么情况下使用身份证，一个人的身份证号码都是不变的。在类加载中，一致性指的是无论通过哪个类加载器加载同一个类，其类定义，在整个应用中都是一致性。运行尝试加载自己写的java.lang.String类：
``` package java.lang; public class String { public static void main(String[] args) { System.out.println(">>> Hello String Class >>>"); } } ``` 运行结果： ``` 错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为: public static void main(String[] args) 否则 JavaFX 应用程序类必须扩展javafx.application.Application Process finished with exit code 1 ``` 问题分析：
当运行自己定义的`java.lang.String` 类时，首先会由系统类加载器（应用程序类加载器）尝试加载这个类。由于类加载的双亲委派机制，当应用程序类加载器在其类加载缓存无法找到`java.lang.String` 类时，它会委托父加载器（扩展类加载器）尝试加载。同样，扩展类加载器也无法找到，会继续委托给引导类加载器。由于引导类加载器负责加载 Java 核心类库，它会在自己的类路径中找到系统提供的 java.lang.String 类。因此，最终执行的是核心类库中的 `java.lang.String` 类，该类没有定义 `main` 方法，导致执行报错。
这个示例，证实了双亲委派机制上述所说的沙箱安全机制特性，它阻止了开发人员在核心类库中创建同名类来替代原有的核心类。这样的机制确保了核心类库的稳定性和一致性，同时也防止了开发人员意外地覆盖核心类的行为。 **全盘负责委托机制：** “全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入。 # 四、自定义类加载器自定义类加载器只需要继承 `java.lang.ClassLoader` 类，该类有两个核心方法，一个是`loadClass(String, boolean)`，实现了双亲委派机制，还有一个方法是`findClass`，默认实现是空方法，所以我们自定义类加载器主要是重写`findClass`方法。
代码示例: ``` package com.jvm.classloader; import java.io.FileInputStream; import java.lang.reflect.Method; 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.replaceAll("\\.", "/"); FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class"); int len = fis.available(); byte[] data = new byte[len]; fis.read(data); fis.close(); return data; } protected Class findClass(String name) throws ClassNotFoundException { try { byte[] data = loadByte(name); //defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。 return defineClass(name, data, 0, data.length); } catch (Exception e) { e.printStackTrace(); throw new ClassNotFoundException(); } } public static void main(String args[]) throws Exception { // 初始化自定义类加载器，会先初始化父类ClassLoader， // 其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader MyClassLoader classLoader = new MyClassLoader("/Users/lan/data/test"); // 在路径/Users/lan/data/test下创建test/com/tuling/jvm 几级目录，将Book1类的复制类Book1.class丢入该目录 Class clazz = classLoader.loadClass("com.jvm.test.Book1"); Object obj = clazz.newInstance(); Method method = clazz.getDeclaredMethod("getName", null); method.invoke(obj, null); System.out.println(clazz.getClassLoader().getClass().getName()); } } } ``` 注意：如果classpath下有`com.jvm.test.Book1`的.class，先删除。
因为自定义加载器的父加载器是程序类加载器（`AppClassLoader`），基于类加载的双亲委派机制，比如我们示例中的`com.jvm.test.Book1`，会被委托给程序类加载器加载，如果classpath下存在此`Book1.class`，输出结果将是：`sun.misc.Launcher$AppClassLoader`。
因此，为了自定义加载器能按预期从路径其类加载路径/Users/lan/data/test下加载`Book1`，需要先删除classpath下的`Book1.class`。 # 五、如何打破双亲委派来一个沙箱安全机制示例，尝试打破双亲委派机制，主要是通过重写类加载`loadClass`方法，实现自己的加载逻辑，不委派给双亲加载。然后用自定义类加载器加载我们自己实现的java.lang.String.class。
代码示例： ``` package com.jvm.classloader; import java.io.FileInputStream; import java.lang.reflect.Method; 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.replaceAll("\.", "/"); FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class"); int len = fis.available(); byte[] data = new byte[len]; fis.read(data); fis.close(); return data; } protected Class findClass(String name) throws ClassNotFoundException { try { byte[] data = loadByte(name); //defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。 return defineClass(name, data, 0, data.length); } catch (Exception e) { e.printStackTrace(); throw new ClassNotFoundException(); } } /** * 重写类加载方法，实现自己的加载逻辑，不委派给双亲加载 * @param name * @param resolve * @return * @throws ClassNotFoundException */ 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) { // 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.getFindClassTime().addElapsedTimeFrom(t1); sun.misc.PerfCounter.getFindClasses().increment(); } if (resolve) { resolveClass(c); } return c; } } public static void main(String args[]) throws Exception { // 初始化自定义类加载器，会先初始化父类ClassLoader， // 其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader MyClassLoader classLoader = new MyClassLoader("/Users/lan/data/test"); // 在路径/Users/lan/data/test下创建java/lang 几级目录，将java.lang.String.class丢入该目录 // 尝试用自己改写类加载机制去加载自己写的java.lang.String.class Class clazz = classLoader.loadClass("java.lang.String"); Object obj = clazz.newInstance(); Method method = clazz.getDeclaredMethod("sout", null); method.invoke(obj, null); System.out.println(clazz.getClassLoader().getClass().getName()); } } } ``` 输出结果： ``` java.lang.SecurityException: Prohibited package name: java.lang at java.lang.ClassLoader.preDefineClass(ClassLoader.java:662) at java.lang.ClassLoader.defineClass(ClassLoader.java:761) at java.lang.ClassLoader.defineClass(ClassLoader.java:642) at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.findClass(MyClassLoaderTest.java:28) at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.loadClass(MyClassLoaderTest.java:53) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.main(MyClassLoaderTest.java:72) Exception in thread "main" java.lang.ClassNotFoundException at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.findClass(MyClassLoaderTest.java:31) at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.loadClass(MyClassLoaderTest.java:53) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.jvm.classloader.MyClassLoaderTest$MyClassLoader.main(MyClassLoaderTest.java:72) ``` 从输出结果，可以看出即使我们自定义的类加载器打破了双亲委派机制，仍然无法成功加载 `java.lang.String`类。
这是因为尽管自定义类加载器打破了双亲委派机制，但是由于 Java 虚拟机的安全性设计，它仍然**通过检查类名是否以 "java." 开头**，禁止加载这些类。这种安全性设计保障了 Java 的稳定性和安全性，防止恶意代码对核心功能造成损害。安全检测的**核心源码**：
![carbon (5).png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c69762c925f47f1b020212d2b890880~tplv-k3u1fbpfcp-watermark.image?) 另外，`java.lang.String.class`位于jre/lib/rt.jar。 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f789db82847945e7add60222d8ae8610~tplv-k3u1fbpfcp-watermark.image?) 解压此jar包，即可获取到String.class： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ac4434d01de445ab9aa62945abcfe6d~tplv-k3u1fbpfcp-watermark.image?) # 写到最后今天，介绍了Java类加载器及双亲委派机制，做下小结： 1. **类加载与加载器分类：** 类的加载是通过类加载器来实现的，主要涉及以下几种加载器： - 引导类加载器（BootstrapClassLoader） - 扩展类加载器（ExtClassLoader） - 应用程序类加载器（AppClassLoader） - 自定义类加载器（CustomClassLoader） 2. **双亲委派机制的作用：** JVM采用双亲委派机制来加载类，具体表现为：在加载类时，会首先自底向上地委派给父加载器，检查是否已加载过，若未找到，再自顶向下尝试加载。这种机制的目的： - 沙箱安全机制 - 类的唯一性保证 - 类的一致性保证 3. **自定义加载器的能力：** JVM允许用户自定义加载器，通常通过重写ClassLoader的findClass方法来实现。这样的自定义加载器可以从指定路径中加载特定的类。
然而，需要注意的是，自定义加载器虽然能够打破双亲委派机制，但它仍然无法加载以`java.`开头的核心类库中的类。 4. **如果打破双亲委派：** 用户可以通过重写类加载方法，不委派给双亲加载，来实现打破双亲委派。
实际应用中，例如Tomcat、JDBC等，这些场景需要在共享的类加载环境中加载不同版本的类，因此采取了自定义的类加载机制，打破了传统的双亲委派机制。