likes
comments
collection
share

Java中为什么要打破双亲委派

作者站长头像
站长
· 阅读数 21

在深入Java的类加载机制时，双亲委派模型无疑是一个核心概念。但为什么在某些情况下我们会选择打破这个原则呢？让我们一探究竟。

1. 什么是双亲委派？

简单来说，当你尝试加载一个类时，Java不会立即加载它。相反，它会询问父加载器是否可以加载这个类。这一过程会递归上溯到顶层加载器。

代码示例：

public class CustomClassLoader extends ClassLoader {

    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        // Check if class is already loaded
        Class<?> cls = findLoadedClass(name);
        if (cls == null) {
            try {
                // Delegate to parent class loader
                cls = getParent().loadClass(name);
            } catch (ClassNotFoundException e) {
                // If not found, try to load class ourselves
                cls = findClass(name);
            }
        }
        return cls;
    }
}

2. 双亲委派的作用和原理

作用：

  • 安全性：Java核心API不能被随意替换，因为启动类加载器只会加载JRE的核心库，这意味着不会加载用户自定义版本的核心Java类库，从而避免了核心API被篡改的安全隐患。
  • 避免类的重复加载：同一个类不会被多次加载，保证了Java对象类型的统一。

原理：

类加载过程遵循“首先询问父类加载器，父类加载器说没有再自己加载”的原则。这确保了例如java.lang.Object这种核心类库不会被用户自定义版本替换或篡改。

3. 为什么要打破双亲委派？

虽然双亲委派提供了安全性，但在某些场合，我们需要更大的灵活性：

  • 热部署：应用服务器如Tomcat在重新部署Web应用时，需要能够隔离旧的应用版本和新的应用版本。这时，它会使用自定义的类加载器来加载新的应用，而不遵循双亲委派。

  • 插件系统：许多大型应用，如IDE或游戏，有自己的插件系统。为了避免插件间的冲突，每个插件可能需要使用其自己的类加载器。

代码示例：

考虑一个简单的插件系统：

public interface Plugin {
    void execute();
}

public class PluginClassLoader extends ClassLoader {
    // Override methods to load from specific locations, 
    // potentially breaking the parent delegation model
}

加载器PluginClassLoader可能需要直接从插件文件或网络位置加载类，而不询问其父加载器。

下面对tomcat打破双亲委派做一个简单的介绍 Tomcat与双亲委派模型

Tomcat是一个流行的Java Web应用服务器，它有一个独特的类加载机制，为了支持Web应用的热部署与隔离，它在某种程度上打破了传统的双亲委派模型。

1. Tomcat的类加载结构

Tomcat有以下的类加载器结构：

  1. Bootstrap ClassLoader：负责加载JRE的核心类库以及Tomcat的核心启动类。
  2. System ClassLoader：负责加载$CATALINA_HOME/bin下的类和库。
  3. Common ClassLoader：负责加载$CATALINA_HOME/lib下的类和库。
  4. WebappX ClassLoader：每一个部署在Tomcat上的Web应用都会有一个属于自己的类加载器。

2. 打破双亲委派

在传统的双亲委派模型中，加载类时首先会委派给父加载器。但是Tomcat打破了这个模型：当WebappX ClassLoader被要求加载类时，它首先尝试加载这个类，而不是委派给其父加载器。只有在本地找不到类时，它才会委派给Common ClassLoader。这样做的好处是，每个Web应用可以有自己的类版本，而不会受到服务器级库的影响。

3. 代码案例

考虑以下场景：两个Web应用都依赖于库A，但是版本不同。因此，每个Web应用在其WEB-INF/lib目录下都有一个版本的A。

如果按照传统的双亲委派模型，那么两个应用都会受到服务器级别（例如$CATALINA_HOME/lib目录下）库的影响，因为首先会尝试在那里加载库。但在Tomcat中，由于其独特的类加载机制，两个应用可以各自加载其WEB-INF/lib目录下的库版本，而不会相互干扰。

代码示例：

假设我们有以下的结构：

webapp1/WEB-INF/lib/A-1.0.jar
webapp2/WEB-INF/lib/A-2.0.jar

当Webapp1中的代码尝试加载库A中的类时：

Class<?> cls = this.getClass().getClassLoader().loadClass("com.example.A");

由于Tomcat的WebappX ClassLoader优先加载本地类库，它将加载A-1.0.jar中的类。同理，Webapp2会加载A-2.0.jar中的类。

4. 总结tomcat打破双亲委派

Tomcat为了支持Web应用的热部署与隔离，采用了一个特殊的类加载策略，打破了传统的双亲委派模型。这确保了Web应用可以独立于服务器级别的库运行，并可以拥有自己版本的类库。当然，这也意味着Web应用开发者需要更加小心，确保他们的应用在Tomcat上运行时，不会因为类版本的冲突而出现问题。

4. 总结

双亲委派模型是Java安全性和类隔离的基石。然而，为了满足特定的需求，如热部署和插件隔离，我们有时需要打破这个模型。这需要深入的技术知识和对Java内部工作方式的了解，但在正确的场景下，这是完全合理的。