【Java编程进阶之路 04】深入探索：Java类加载器与双亲委派 & 打破双亲委派桎梏
导言
在Java的世界里，类加载器（ClassLoader）是一个核心组件，它负责在运行时动态加载Java类到JVM中。为了确保Java应用的安全和稳定，Java设计者们引入了一种称为“双亲委派模型”（Parent Delegation Model）的类加载机制。这种机制不仅避免了类的重复加载，还保护了系统的安全。下面我们将详细探讨双亲委派机制的工作原理、优势、以及它在Java生态系统中的应用。
01 双亲委派模型的基本概念
双亲委派模型是Java类加载机制中的核心概念，它的基本概念可以分为以下几点进行分点描述：
- 层次结构：双亲委派模型要求除了顶层的启动类加载器（Bootstrap ClassLoader）外，其余的类加载器都应当有自己的父类加载器。这种层次结构确保了类加载的顺序和一致性。
- 委派机制：当一个类加载器收到类加载请求时，它不会立即尝试加载这个类，而是将这个请求委派给它的父类加载器。这种委派机制确保了类加载的优先级和顺序，即先由父类加载器尝试加载，只有当父类加载器无法加载时，子类加载器才会尝试加载。
- 唯一性：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性。这意味着同一个类只能被一个类加载器加载一次，避免了类的重复加载。
- 安全性：双亲委派模型通过委派机制，可以防止核心API类被随意篡改，从而保护了系统的安全性。因为所有的类加载请求最终都会传送到顶层的启动类加载器中，而启动类加载器只加载核心类库，所以恶意代码无法通过自定义类来攻击系统。
- 代码热部署：双亲委派模型还支持代码的热部署。在需要动态更新代码的场景中，可以通过自定义类加载器来加载新的类文件，而不会影响已经运行中的代码。这种机制使得系统在不重启的情况下，能够动态更新和扩展功能。
综上所述，双亲委派模型通过层次结构、委派机制、唯一性、安全性和代码热部署等方面的特性，确保了Java类加载机制的高效性、安全性和灵活性。
02 双亲委派模型的工作流程
双亲委派模型的工作流程是Java类加载机制的核心，它确保了类加载的层次性和安全性。下面我将详细描述这个流程，并提供相关的代码片段来进一步说明。
-
加载请求：当一个类需要被加载时（例如，当你首次引用一个类时），会由对应的类加载器发起加载请求。
-
委派给父类加载器：类加载器收到加载请求后，不会立即尝试加载这个类，而是首先将这个请求委派给它的父类加载器。如果类加载器是
ClassLoader的子类，它会调用loadClass方法，并将加载请求传递给父类加载器。 -
父类加载器的处理：父类加载器收到加载请求后，会先检查这个类是否已经被加载过。如果已经加载过，就直接返回这个类的
Class对象。如果没有加载过，父类加载器会尝试自己去加载这个类。 -
递归委派：这个过程会一直递归进行，直到到达最顶层的启动类加载器（Bootstrap ClassLoader）。启动类加载器是Java虚拟机的一部分，它负责加载核心类库（如
java.lang.String等）。 -
父类加载器无法加载：如果父类加载器无法加载这个类（例如，它不在父类加载器的搜索路径中），加载请求会返回给子类加载器。
-
子类加载器尝试加载：子类加载器收到父类加载器的失败通知后，会尝试自己加载这个类。它首先会检查自己的类路径（ClassPath）中是否包含这个类的字节码文件。
-
加载类：如果子类加载器找到了这个类的字节码文件，它会加载这个文件并返回对应的
Class对象。如果没有找到，子类加载器会抛出ClassNotFoundException异常。 -
返回Class对象：无论是由父类加载器还是子类加载器加载的类，最终都会返回对应的
Class对象，这个对象可以被用来创建类的实例或访问类的静态成员。
代码片段示例
下面是一个简单的示例代码，展示了类加载器如何按照双亲委派模型加载类：
public class CustomClassLoader extends ClassLoader {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
// 1. 检查这个类的字节码是否已经被加载过
Class<?> loadedClass = findLoadedClass(name);
if (loadedClass == null) {
try {
// 2. 如果没有加载过，则委派给父类加载器加载
loadedClass = getParent().loadClass(name);
} catch (ClassNotFoundException e) {
// 3. 父类加载器无法加载，则自己尝试加载
loadedClass = findClass(name);
}
}
return loadedClass;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 4. 自定义加载逻辑，例如从文件系统或网络中加载类的字节码文件
// 这里只是简单地抛出一个异常作为示例
throw new ClassNotFoundException("Class not found by CustomClassLoader: " + name);
}
public static void main(String[] args) {
// 创建一个自定义的类加载器实例
CustomClassLoader classLoader = new CustomClassLoader();
// 尝试加载一个类
try {
Class<?> clazz = classLoader.loadClass("com.example.MyClass");
// 如果加载成功，可以使用clazz来创建实例或访问静态成员
System.out.println("Class loaded successfully: " + clazz.getName());
} catch (ClassNotFoundException e) {
// 如果加载失败，会抛出ClassNotFoundException异常
System.out.println("Failed to load class: " + e.getMessage());
}
}
}
在这个示例中，CustomClassLoader是一个自定义的类加载器，它继承自ClassLoader。loadClass方法覆盖了父类的方法，以实现双亲委派模型的逻辑。如果父类加载器无法加载类，findClass方法会被调用，这里可以自定义加载类的逻辑。在这个简单的示例中，findClass方法只是抛出了一个ClassNotFoundException异常，表示没有找到类的字节码文件。
请注意，在实际应用中，findClass方法通常会包含从文件系统、网络或其他来源加载类字节码文件的逻辑。此外，对于Java的核心类库，启动类加载器会直接加载，而不会通过双亲委派模型。
03 双亲委派模型的优势
双亲委派模型的设计带来了以下几个优势：
-
避免类的重复加载：由于所有的类加载请求都会先委派给父类加载器，这就保证了同一份类数据（同一个类名）只会在虚拟机中出现一次，避免了类的重复加载。这不仅可以节省内存空间，还可以提高系统的性能。
-
保护系统的安全：双亲委派模型可以防止核心API类被随意篡改。假设通过网络传递一个名为java.lang.String的类，通过双亲委派模型传递到启动类加载器，而启动类加载器在核心Java API中发现了这个名字，那么它会认为这个类是不合法的，从而拒绝加载这个类。这样就可以防止恶意代码通过自定义类来攻击系统。
-
实现代码的热部署：在一些需要动态更新代码的场景中（如Web服务器），双亲委派模型可以方便地实现代码的热部署。当需要更新某个类时，只需要简单地替换掉原来的类文件即可。由于新的类文件是由一个新的类加载器来加载的，所以不会影响到已经运行中的代码。这样就可以在不重启服务器的情况下实现代码的更新。
04 双亲委派模型在Java生态系统中的应用
在Java生态系统中，双亲委派模型被广泛应用在各种类型的类加载器中。除了前面提到的启动类加载器、扩展类加载器和应用程序类加载器外，还有一些自定义的类加载器也遵循双亲委派模型。比如Tomcat中的Webapp类加载器就遵循了双亲委派模型。当一个Web应用需要加载某个类时，它会首先把这个请求委派给它的父类加载器（通常是系统类加载器）去完成。只有当父类加载器无法加载这个类时，Webapp类加载器才会尝试自己去加载这个类。
- 自定义类加载器：在Java生态系统中，开发者可以通过继承
java.lang.ClassLoader类来创建自定义的类加载器。在创建自定义类加载器时，需要重写findClass方法，并通常会在该方法中调用defineClass方法来定义类。然而，在实际应用中，开发者通常不需要重写loadClass方法，因为loadClass方法已经实现了双亲委派模型的逻辑。 - 热部署和热替换：在某些场景下，如Web应用服务器（如Tomcat）中，可能需要实现热部署和热替换功能，即在不重启服务器的情况下，动态地加载和替换类。这时，自定义类加载器可以实现热部署和热替换，但需要特别注意双亲委派模型的应用，以避免类冲突和安全问题。
- 模块化系统：Java 9引入了模块化系统（JPMS），其中每个模块都有自己的类加载器。这些类加载器遵循双亲委派模型，以确保模块之间的隔离和安全性。
- OSGi：OSGi（Open Service Gateway initiative）是一个面向Java的模块化系统和服务平台。在OSGi中，每个Bundle都有自己的类加载器，这些类加载器也遵循双亲委派模型，以确保Bundle之间的隔离和安全性。然而，OSGi对双亲委派模型进行了一些扩展，以实现更灵活的类加载和卸载机制。
总之，Java双亲委派模型在Java生态系统中具有广泛的应用，它确保了Java应用程序的类加载安全，避免了类冲突和重复加载等问题。在开发自定义类加载器、实现热部署和热替换、使用模块化系统以及OSGi等场景中，都需要特别注意双亲委派模型的应用。
05 如何打破双亲委派模型
在Java中，打破双亲委派模型通常是为了满足一些特殊的需求，比如实现热部署、插件化、或者加载一些非核心类库的代码。虽然打破双亲委派模型可以带来一些灵活性，但它也可能引入安全风险，因此应该谨慎使用。
打破双亲委派模型的主要方法是自定义类加载器，并重写loadClass方法，使其不再遵循双亲委派模型的逻辑。下面是一个简单的示例，展示了如何打破双亲委派模型：
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.lang.instrument.ClassFileTransformer;
import java.lang.instrument.Instrumentation;
import java.security.ProtectionDomain;
public class CustomClassLoader extends ClassLoader {
private final Instrumentation instrumentation;
public CustomClassLoader(ClassLoader parent, Instrumentation instrumentation) {
super(parent);
this.instrumentation = instrumentation;
}
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
// 自定义类加载逻辑，不遵循双亲委派模型
if (name.startsWith("com.example.custom")) {
try {
byte[] classBytes = loadClassData(name);
Class<?> clazz = defineClass(name, classBytes, 0, classBytes.length);
return clazz;
} catch (Exception e) {
throw new ClassNotFoundException("Failed to load class: " + name, e);
}
}
// 默认情况下，仍然使用双亲委派模型
return super.loadClass(name);
}
private byte[] loadClassData(String name) throws IOException {
// 这里是加载类数据的逻辑，可以根据需要实现
// 例如，可以从文件系统、网络或其他资源中加载类数据
// 这里为了简化示例，直接返回空字节数组
return new byte[0];
}
// 可以通过Java Agent注入的方式提供Instrumentation实例
public static void premain(String agentArgs, Instrumentation inst) {
// 这里是Agent的premain方法，用于设置自定义类加载器
// 可以将自定义类加载器注册到某个特定线程或应用到整个JVM
}
}
在上面的示例中，CustomClassLoader类重写了loadClass方法，并在其中添加了自定义的类加载逻辑。当需要加载以com.example.custom开头的类时，它不会遵循双亲委派模型，而是直接调用defineClass方法来定义类。这样就打破了双亲委派模型。
需要注意的是，在打破双亲委派模型时，应该非常小心处理类加载的安全性和隔离性。自定义类加载器需要仔细处理类数据的加载和验证，以避免加载恶意代码或破坏类的不变性。
此外，在Java 9及以上版本中，模块化系统引入了一些新的类加载机制，包括java.lang.module.ModuleFinder和java.lang.module.ModuleLayer等，这些机制可以用来实现更加灵活和安全的类加载策略。在开发新的应用程序时，建议优先考虑使用Java的模块化系统来满足特殊需求，而不是简单地打破双亲委派模型。
5.1 线程上下文类加载器
线程上下文类加载器（Thread Context Classloader，简称TCCL）是Java提供的一种机制，允许每个线程都有一个与之关联的类加载器。这个类加载器可以用来加载资源，通常是在使用诸如ClassLoader.getSystemResource()或Thread.currentThread().getContextClassLoader().getResource()等方法时。
这种机制的主要用途是允许在一个线程中运行的代码使用不同于创建该线程时所使用的类加载器来加载类和资源。这对于在Web服务器（如Tomcat）中实现插件化、热部署等功能非常有用。
下面是一个简单的示例，展示了如何使用线程上下文类加载器：
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
public class ThreadContextClassLoaderExample {
public static void main(String[] args) {
// 设置系统默认的类加载器
System.out.println("System class loader: " + Thread.currentThread().getContextClassLoader());
// 创建一个新的类加载器
ClassLoader customClassLoader = new CustomClassLoader();
// 设置线程上下文类加载器
Thread.currentThread().setContextClassLoader(customClassLoader);
// 获取线程上下文类加载器
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
System.out.println("Context class loader: " + contextClassLoader);
// 使用线程上下文类加载器加载资源
try {
URL resourceUrl = contextClassLoader.getResource("example.txt");
if (resourceUrl != null) {
try (InputStream inputStream = resourceUrl.openStream()) {
// 读取资源内容
byte[] buffer = new byte[1024];
int bytesRead = inputStream.read(buffer);
if (bytesRead > 0) {
System.out.println("Loaded resource content: " + new String(buffer, 0, bytesRead));
}
}
} else {
System.out.println("Resource not found");
}
} catch (IOException e) {
e.printStackTrace();
}
// 恢复系统默认的类加载器
Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoader());
}
// 自定义类加载器
static class CustomClassLoader extends ClassLoader {
@Override
public URL findResource(String name) {
// 在这里实现自定义的资源查找逻辑
// 例如，可以从文件系统、网络或其他源加载资源
return super.findResource(name);
}
}
}
在这个示例中，我们首先打印出当前线程的上下文类加载器，它通常是系统默认的类加载器。然后，我们创建了一个自定义的类加载器CustomClassLoader，并将其设置为当前线程的上下文类加载器。接着，我们使用getContextClassLoader()方法获取线程上下文类加载器，并使用它来加载一个名为example.txt的资源。最后，我们恢复了系统默认的类加载器。
请注意，在实际应用中，自定义类加载器的实现可能会更加复杂，需要处理各种类加载的边界情况和安全性问题。此外，线程上下文类加载器通常只在特定的应用场景中使用，例如在Web服务器中实现插件化或热部署。在一般的Java应用程序中，通常不需要使用线程上下文类加载器。
5.2 类加载器的代理模式
在Java中，双亲委派模型（Parent Delegation Model）是类加载器默认遵循的一种模型，其中每个类加载器在加载类之前，会先让其父类加载器尝试加载。这种模型有助于确保Java核心API的稳定性和安全性，因为核心类只能由引导类加载器（Bootstrap Class Loader）加载，而引导类加载器是由JVM实现的，并且它优先于所有其他类加载器。
然而，在某些情况下，可能需要打破双亲委派模型。这通常是为了实现更复杂的类加载策略，例如热部署、插件化、代码隔离等。打破双亲委派模型的一种常见方法是使用类加载器的代理模式，即自定义类加载器不直接加载类，而是委托给另一个类加载器去加载。
下面是一个简单的示例，展示了如何通过自定义类加载器来打破双亲委派模型：
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;
public class CustomClassLoader extends ClassLoader {
private final ClassLoader parent;
public CustomClassLoader(ClassLoader parent) {
this.parent = parent;
}
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
// 首先尝试自己加载类
try {
return findClass(name);
} catch (ClassNotFoundException e) {
// 如果自己加载失败，则让父类加载器尝试加载
try {
return parent.loadClass(name);
} catch (ClassNotFoundException ex) {
// 如果父类加载器也加载失败，则抛出异常
throw ex;
}
}
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 这里实现了自定义的类加载逻辑
// 例如，可以从文件系统、网络或其他源加载类
byte[] classData = loadClassData(name);
if (classData == null) {
throw new ClassNotFoundException("Class not found: " + name);
}
return defineClass(name, classData, 0, classData.length);
}
private byte[] loadClassData(String name) {
// 加载类的具体实现，这里仅作为示例
// 实际情况下，可能需要从文件系统、网络或其他资源加载类数据
String className = name.replace(".", "/");
try (InputStream in = getClass().getResourceAsStream(className + ".class")) {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int data;
while ((data = in.read()) != -1) {
baos.write(data);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
public static void main(String[] args) throws Exception {
// 创建一个自定义类加载器，将系统类加载器作为父类加载器
CustomClassLoader customClassLoader = new CustomClassLoader(ClassLoader.getSystemClassLoader());
// 使用自定义类加载器加载一个类
Class<?> myClass = customClassLoader.loadClass("com.example.MyClass");
// 创建类的实例
Object instance = myClass.newInstance();
// 调用类的方法
Method method = myClass.getMethod("hello");
method.invoke(instance);
}
}
在这个示例中，CustomClassLoader 类继承自 ClassLoader，并重写了 loadClass 和 findClass 方法。loadClass 方法首先尝试调用 findClass 方法来加载类，如果失败，则调用父类加载器的 loadClass 方法。findClass 方法是自定义类加载逻辑的核心，它负责从指定的资源中加载类的字节码数据，并使用 defineClass 方法将字节码数据定义为一个 Class 对象。
请注意，这个示例仅用于演示如何打破双亲委派模型，并不是一个完整的、可用于生产环境的类加载器实现。在实际应用中，自定义类加载器可能需要处理更多的边界情况和安全性问题。此外，还需要确保加载的类与系统的其他部分兼容，并避免类冲突和重复加载等问题。
5.3 使用Java Agent和Instrumentation API
Java Agent是一种特殊的JAR文件，可以在JVM启动时或运行时被加载。通过Java Agent和Instrumentation API，可以在字节码级别修改类的定义。这意味着你可以在类被加载到JVM之前修改其字节码，从而改变类的行为。虽然这种方式不直接打破双亲委派模型，但它允许你以非常灵活的方式影响类的加载和定义。
使用Java Agent和Instrumentation API可以让我们在运行时修改类的字节码，这提供了一种方式来打破双亲委派模型。Java Agent是一个特殊的JAR文件，它包含一个特殊的类，即premain方法，它在JVM启动时被调用。使用Java Agent，我们可以在类被加载到JVM之前修改其字节码。
以下是如何使用Java Agent和Instrumentation API来打破双亲委派模型相关示例：
步骤 1: 编写一个Java Agent
首先，你需要创建一个包含premain方法的Java类。premain方法将在JVM启动时被调用，并且可以在类加载之前应用转换。
import java.lang.instrument.Instrumentation;
public class MyAgent {
public static void premain(String agentArgs, Instrumentation inst) {
// 这里是agent的入口点，可以在类加载之前做一些事情
System.out.println("MyAgent loaded with arguments: " + agentArgs);
// 使用Instrumentation API来定义类加载器的行为
}
}
步骤 2: 打包Java Agent
将你的Java Agent类打包成一个JAR文件，并且需要在MANIFEST.MF文件中指定Premain-Class属性，以告诉JVM哪个类包含premain方法。
Manifest-Version: 1.0
Premain-Class: MyAgent
步骤 3: 使用Java Agent
在运行Java程序时，你需要使用-javaagent选项来指定你的Java Agent JAR文件。
sh复制代码java -javaagent:myagent.jar MyApplication
步骤 4: 使用Instrumentation API进行字节码操作
在premain方法中，你可以使用Instrumentation实例来注册类转换器，它允许你在类加载之前或之后修改类的字节码。
以下是一个简单的类转换器示例，它将打印出每个被加载的类的名称：
import java.lang.instrument.ClassFileTransformer;
import java.lang.instrument.IllegalClassFormatException;
import java.security.ProtectionDomain;
public class MyClassTransformer implements ClassFileTransformer {
@Override
public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
System.out.println("Transforming class: " + className);
// 在这里可以修改classfileBuffer来修改类的字节码
// 注意，通常不需要这样做，除非你有特殊的字节码操作需求
return classfileBuffer;
}
}
步骤 5: 在premain方法中注册类转换器
在你的premain方法中，你需要注册你的类转换器。
public static void premain(String agentArgs, Instrumentation inst) {
System.out.println("MyAgent loaded with arguments: " + agentArgs);
// 注册类转换器
inst.addTransformer(new MyClassTransformer(), true);
}
在这个例子中，true参数意味着转换器将应用于已加载的类以及将要加载的类。
示例代码
以下是将所有这些步骤结合在一起的示例代码。
MyAgent.java
import java.lang.instrument.ClassFileTransformer;
import java.lang.instrument.Instrumentation;
import java.security.ProtectionDomain;
public class MyAgent {
public static void premain(String agentArgs, Instrumentation inst) {
System.out.println("MyAgent loaded with arguments: " + agentArgs);
// 注册类转换器
inst.addTransformer(new MyClassTransformer(), true);
}
public static class MyClassTransformer implements ClassFileTransformer {
@Override
public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
System.out.println("Transforming class: " + className);
// 这里不修改字节码，只是打印类名
return classfileBuffer;
}
}
}
在MANIFEST.MF中指定Premain-Class：
Manifest-Version: 1.0
Premain-Class: MyAgent
然后，将MyAgent类打包成myagent.jar文件，并使用-javaagent选项运行你的应用程序。
注意，这个例子没有直接打破双亲委派模型，只是展示了如何使用Java Agent和Instrumentation API来修改类加载过程。要打破双亲委派模型，可能需要在类转换器中修改字节码。
5.4 使用OSGi或其他模块化框架
在使用OSGi（Open Service Gateway initiative）或其他模块化框架时，打破Java的双亲委派模型是常见的做法，因为这些框架需要更细粒度的控制和管理类加载。OSGi提供了一种名为"类加载器隔离"的机制，它允许每个模块（在OSGi中称为"bundle"）有自己的类加载器，从而打破了双亲委派模型。
在OSGi中，每个bundle都有一个自己的类加载器，这些类加载器之间是相互隔离的。当一个bundle需要加载一个类时，它首先会尝试使用自己的类加载器来加载，如果加载失败，它会向它的父类加载器（通常是框架的类加载器）请求加载。这与双亲委派模型不同，因为在双亲委派模型中，子类加载器会首先请求父类加载器加载类。
下面是如何在OSGi中打破双亲委派模型的一些步骤：
-
创建OSGi Bundle：首先，你需要使用适当的工具（如Maven的Bundle插件）创建一个OSGi bundle。这个bundle将包含你的代码和资源。
-
定义导出和导入的包：在你的bundle的manifest文件中，你需要定义哪些包应该被导出（供其他bundles使用）和哪些包应该被导入（从你的bundles中使用）。
-
使用OSGi类加载器：在OSGi环境中，你的代码将自动使用bundle的类加载器来加载类。这个类加载器会首先尝试从bundle自己的classpath中加载类，如果找不到，它会向父类加载器请求。
-
自定义类加载逻辑：如果需要，你可以通过实现
BundleClassLoader的自定义版本来控制类加载的逻辑。你可以覆盖loadClass方法来实现自己的加载策略。 -
使用服务注册和查找：在OSGi中，服务是组件之间交互的主要方式。你可以注册服务（提供功能）和查找服务（使用功能）。这允许bundles之间的解耦和动态交互。
-
避免类冲突：由于每个bundle都有自己的类加载器，因此可能存在类冲突的风险。确保你的bundles不会尝试加载相同全限定名的类，或者如果它们这样做，确保这些类是兼容的。
-
测试和调试：在OSGi环境中开发和调试代码可能比传统的Java应用程序更复杂。确保你使用适当的工具和技术来测试和调试你的bundles。
记住，虽然OSGi打破了双亲委派模型，但它仍然提供了一种机制来确保类加载的一致性和隔离性。这是通过类加载器的层次结构和适当的类加载策略实现的。
06 小结
双亲委派模型是Java类加载机制中的一个重要概念，它保证了Java应用的安全和稳定。通过委派加载请求给父类加载器，可以避免类的重复加载和保护系统的安全；通过实现代码的热部署，可以方便地更新运行中的代码。在Java生态系统中，各种类型的类加载器都遵循这一模型，从而保证了Java应用的正常运行。
当然，双亲委派模型也不是完美无缺的。在某些特殊场景下（如需要加载不同版本的同一个类），可能需要打破这一模型。
- 点赞
- 收藏
- 关注作者
评论（0）