为什么要打破双亲委派机制

双亲委派机制是Java类加载器的一种经典实现方式，它是指一个类加载器在加载类时，会先将加载请求委派给父类加载器去完成，只有在父类加载器无法完成加载请求时，才会自己去加载。这种机制保证了Java类库的安全性和稳定性。但是，在某些特定的应用场景下，双亲委派机制也可能会导致问题。

一般情况下，双亲委派机制可以有效避免类的重复加载和保证类的唯一性，但是在某些情况下，可能需要打破这个机制。例如，当我们需要在同一个JVM中使用多个版本的同一个类时，由于双亲委派机制的存在，较新版本的类无法被加载，因为父类加载器已经加载了较旧版本的类。此时，我们需要打破双亲委派机制，使用自定义的类加载器来加载指定版本的类。

此外，在一些特定场景下，比如应用程序需要热部署、动态更新等功能时，也需要打破双亲委派机制。因为在这种情况下，我们需要动态地卸载和加载类，而双亲委派机制并不支持动态卸载已经加载的类。

相关问题

双亲委派机制，好处是什么，为什么要打破双亲委派机制，tomcat怎么打破双亲委派机制的？

双亲委派机制（Parent-Delegation Model）是Java类加载器体系结构中的一项重要设计，它的工作原理是在类被请求时，先由当前类加载器寻找，如果找不到再委托给父级加载器查找。这样做的好处主要有：

1. 安全性：防止恶意代码替换系统类库，因为每个类加载器只负责加载自己的路径下的类。

2. 隔离性：避免类名冲突，子类加载器不会覆盖父加载器已经加载过的类。

然而，有时可能需要打破这种机制，比如：

1. 自定义类加载：当开发者希望在特定环境或上下文中动态加载类，例如Web应用程序中的Spring框架或第三方库可能需要自定义类加载策略。

2. 组合加载器：为了兼容多个版本的库或者需要处理不同版本之间的依赖冲突。

Tomcat作为Java Web应用服务器，提供了几种方法来打破双亲委派机制：

1. 使用`java.lang.instrument包`：这个API允许动态修改运行时类文件，可以在应用启动后，通过ClassFileTransformer接口改变类加载行为。

2. 在web.xml中配置`<loader>`元素：对于Servlet或JSP等资源，可以通过 `<Context>` 标签内的 `<Loader>` 元素来指定一个非标准的类加载器，如`org.springframework.web.context.support.AnnotationConfigWebApplicationContext$AnnotationConfigwarClassLoader`。

3. 使用`WebappLoader`或`CustomClassLoader`：这些类允许创建一个自定义的类加载器，用于Tomcat应用中的某个特定区域。

总之，打破双亲委派机制是为了满足特殊需求，但在实际操作中需要谨慎，因为它可能会引入安全风险和复杂性。

java的spi机制为什么要打破双亲委派机制

Java的SPI机制在加载第三方服务提供者的实现时，会使用线程上下文类加载器（Thread Context ClassLoader），而不是使用父类加载器（Parent ClassLoader）。

这是因为在双亲委派机制下，父类加载器无法访问子类加载器加载的类，而SPI机制需要访问应用程序中的第三方服务提供者的实现类，这些实现类可能是由子类加载器加载的。因此，使用线程上下文类加载器可以打破双亲委派机制的限制，从而实现SPI机制的动态加载。

另外，SPI机制的实现类通常是由第三方提供商提供的，而不是由应用程序开发者提供的。这些实现类可能依赖于某些特定的库或框架，这些库或框架的类可能无法被父类加载器加载。在这种情况下，使用线程上下文类加载器可以确保SPI机制的实现类能够被正确加载。

需要注意的是，打破双亲委派机制可能会带来安全隐患，因此应该谨慎使用线程上下文类加载器来加载类。在实现SPI机制时，应该尽可能地控制第三方提供商的实现，避免出现安全问题。