Java中不同类加载器的需求是什么

Question

我已经读过Java中有不同的类加载器，一种是原始类加载器，也有自定义类加载器，所以我想了解为什么原始类加载器不能为Java中的所有类提供服务？ 为什么需要其他类装载机？

Answer 1

主要需要是隔离。

假设页面上有3个applet，每个applet使用库foo.jar的不同版本。 您希望每个小程序都使用其自己的库版本运行，并确保它不会在另一个小程序的脚趾上行走。 这要归功于不同的类加载器。

部署在单个容器上的Web应用程序也是如此。 启动Java容器时未部署任何应用程序，然后部署了应用程序。 您希望容器能够从甚至不知道何时启动的位置加载类。 而且，如果部署了另一个Web应用程序，则您希望该其他应用程序具有自己的类和库，这些类和库与第一个应用程序的类和库是不同的并且是隔离的。

另一个需求是能够从各个位置加载类：文件系统，但也可以加载URL，数据库等。

Answer 2

在许多实际情况下，您需要功能超出系统类装入器提供的功能：

1. 您可以授予自定义类来源的访问权限（例如，通过http）
2. 您可以缓存数据块（例如，“如果需要此类，那么让我预加载这些其他类”）
3. 您可以合并防止某些类加载的安全协议
4. 您可以保留使用了什么类的统计信息，以便以后优化jar档案
5. 您可以在加载类时执行字节码转换（“加载时编织”），例如，修改适合特定模式的类。 面向方面的编程实现可以使用此技术。

最后一点特别强大（这也是我使用它们的主要原因）。 由于Java字节码在各个平台之间是通用的，因此您可以使用它来检测任何系统上的类：测量调用了哪些方法，抑制对安全性要求很高的调用，将System.out访问转移到您自己的自定义日志记录例程，或者执行高级的动态错误测试。例行程序。

Answer 3

原因之一是安全性。 例如，默认（程序包专用）可见性级别仅允许访问相同程序包中的类， 并由相同的类加载器加载 。 这使得恶意代码更难以访问您的内部API。

参考文献：

• URLClassLoader和包专用方法的可访问性
• 覆盖包私有方法的精妙之处

Answer 4

假设您正在开发应用程序服务器。 根据要求，您希望在服务器启动时加载类。 原始加载器不知道您的要求，因此您需要编写自己的类加载器。

为什么要编写自定义类加载器

Answer 5

这个答案很好地总结了为什么即使您可以也不希望对所有类都使用相同的类加载器：

ClassLoader在大型系统和服务器应用程序中用于执行以下操作：

• 模块化系统并在运行时加载，卸载和更新模块
• 并行使用不同版本的API库（例如XML解析器）
• 隔离在同一JVM中运行的不同应用程序（确保它们不会相互干扰，例如通过静态变量）

Answer 6

类装载器的类型：

1. 引导带类加载器/前代类加载器
2. 扩展类加载器
3. 应用程序类加载器/系统类加载器

Boot Strap类加载器 ：负责加载核心JAVA API类，即rt.jar中存在的类

rt.jar的位置-> jdk / jre / lib / rt.jar，也称为引导程序类路径。

Bootstrap类加载器从Bootstrap类路径加载类。 Bootstrap是用C或C ++等本机语言实现的，而不是用JAVA实现的。

扩展类加载器：从扩展类路径（即jdk / jre / lib / ext / *。jar）加载类

扩展类加载器是BootStrapClassLoader的子级，它是用JAVA实现的。

对应的JAVA类是sun.misc.Launcher$ExtClassLoader.class

应用程序类加载器：扩展类加载器的子类。 应用程序类加载器从应用程序类路径加载类。 它在内部使用环境类路径。

它在JAVA中实现。 对应的JAVA类是sun.miscLauncher$AppClassLoader.class

类加载器遵循委托层次结构原则 。 每当JVM遇到特定类时，它都会首先检查.class文件的加载位置。 如果已在方法区域中加载了该类，则JVM将考虑该已加载的类，如果不是，则JVM将请求Class Loader Subsystem来加载特定的类。 Class Loader子系统将请求移交给应用程序类加载器，将请求委托给Extension Class加载器，然后委托给BootStrap Class loader，后者搜索引导类路径（如果找不到），Extension Class loader搜索扩展类路径，如果找不到，则查找Application类laoder搜索应用程序类路径，如果仍然找不到该类，则将发生ClassNotFoundException或NoClassDefFoundError。