JVM 如何打破双亲委派模型？

虽然双亲委派模型是 Java 类加载机制的推荐实现方式，但在某些情况下，为了实现特定的功能，可能需要打破双亲委派模型。以下是一些常见的打破双亲委派模型的方法和场景：

1. 重写 loadClass 方法 (不推荐):

原理： java.lang.ClassLoader 的 loadClass 方法实现了双亲委派模型的逻辑。默认情况下，loadClass 方法会先检查类是否已经被加载过，如果没有，则委托给父类加载器加载。如果父类加载器无法加载，则调用 findClass 方法尝试自己加载。
打破方式： 重写 loadClass 方法，不遵循双亲委派模型的逻辑，而是直接调用 findClass 方法尝试自己加载类，或者自定义加载逻辑。

示例：

public class MyClassLoader extends ClassLoader {@Overridepublic Class<?> loadClass(String name) throws ClassNotFoundException {// 不再委托给父类加载器，直接尝试自己加载return findClass(name); }@Overrideprotected Class<?> findClass(String name) throws ClassNotFoundException {// 实现自定义的类加载逻辑// ...}
}

缺点：
- 破坏了双亲委派模型的优点： 可能会导致类的重复加载、核心类库被篡改等问题。
- 容易出错： 需要自己处理类加载的各种细节，容易出错。
- 不推荐： 除非有非常特殊的需求，否则不建议重写 loadClass 方法。

2. 使用线程上下文类加载器 (Thread Context ClassLoader):

原理：
- 每个线程都有一个关联的上下文类加载器 (Context ClassLoader)。
- 可以通过 Thread.currentThread().getContextClassLoader() 获取当前线程的上下文类加载器。
- 可以通过 Thread.currentThread().setContextClassLoader(ClassLoader cl) 设置当前线程的上下文类加载器。
- 如果没有设置，线程上下文类加载器默认是应用程序类加载器 (AppClassLoader)。
打破方式：
- 在需要打破双亲委派模型的地方，获取当前线程的上下文类加载器，并使用它来加载类。
- 例如，JDBC 驱动程序通常由应用程序类加载器加载，但 JDBC API (如 java.sql.DriverManager) 需要能够加载这些驱动程序。DriverManager 会使用线程上下文类加载器来加载驱动程序。
应用场景：
- SPI (Service Provider Interface): Java 中的 SPI 机制（例如 JDBC、JNDI、JAXP 等）通常使用线程上下文类加载器来加载服务提供者的实现类。
- 框架和容器： 一些框架和容器（例如，Tomcat、Spring）会使用线程上下文类加载器来加载应用程序的类或资源。
示例：

       // 获取当前线程的上下文类加载器ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();// 使用上下文类加载器加载类try {Class<?> myClass = contextClassLoader.loadClass("com.example.MyClass");// ...} catch (ClassNotFoundException e) {// ...}

3. 自定义类加载器并重写 findClass 方法 (推荐):

原理:
- 继承 java.lang.ClassLoader，并重写 findClass 方法。
- 在 findClass 方法中实现自己的类加载逻辑，例如从特定的目录、URL 或数据库中加载类。
优点:
- 可以灵活地控制类的加载过程。
- 可以实现一些特殊的功能，例如热部署、模块化等。
示例: (前面已经提供过，此处不再重复)

4. OSGi (Open Service Gateway initiative):

原理：
- OSGi 是一个模块化系统，每个模块（bundle）都有自己的类加载器。
- OSGi 的类加载器模型不是严格的双亲委派模型，而是更复杂的网状结构。
- OSGi 允许模块显式地声明它们依赖的其他模块，以及它们导出的包。
- OSGi 框架会根据这些声明来解析模块之间的依赖关系，并加载相应的类。
打破方式： OSGi 的类加载器模型本身就不是双亲委派模型。

5. Tomcat 的类加载器:

原理:
- Tomcat 为了实现 Web 应用程序之间的隔离，以及共享库的加载，使用了多个类加载器。
- Tomcat 的类加载器结构：
  - Bootstrap: 加载 JVM 启动所需的类。
  - System: 加载 Tomcat 自身的类。
  - Common: 加载 Tomcat 和所有 Web 应用程序都可以访问的类 (例如, JDBC 驱动)。
  - WebappX: 每个 Web 应用程序都有一个独立的 WebAppClassLoader，负责加载该应用程序的类 (位于 WEB-INF/classes 和 WEB-INF/lib 目录下).
  - Shared: (可选) 存放所有web应用共享的类.
加载顺序:
1. Bootstrap
2. System
3. Common
4. WebappX (先在 WEB-INF/classes 中查找, 再在 WEB-INF/lib 中查找，最后才委托给父类加载器).
5. Shared (如果配置了的话)
打破双亲委派:
- WebAppClassLoader 会优先在自己的范围内查找类，而不是立即委托给父类加载器, 这打破了双亲委派模型。
- 这样做的好处是：
  - 隔离性： 不同的 Web 应用程序可以使用不同版本的类库，而不会相互干扰。
  - 灵活性： Web 应用程序可以覆盖 Tomcat 或共享库提供的类。