那好吧

常见的应用程序具有3个标准的类加载器：

1. 引导类加载器
2. 扩展类加载器
3. 系统类路径类加载器

到目前为止，一切都很好。现在，这适用于 单独 运行且免费运行的 单个 应用程序。

但是，当您说 J2EE时会 怎样？您有 多个应用程序 在同一个地方运行，因此您必须找出一种防止它们 相互绊倒
的方法。这就是这些额外的类加载器的作用。

考虑一个服务器实例。有一个带有两个已部署EAR的JBoss。如果 应用程序之间的类冲突，
将会发生什么？他们在自己的特定上下文中可以接受，但总体上并不一致。

这些额外的类加载器以应用程序方式引入，以 确保它们之间的隔离 。 System-Classpath 下 的类加载器
只有在清单文件中为其子级之一指定的类时， 类加载器才 识别类。

在J2SE中，三个基本类加载器基于以下三个原则以父子关系工作：

1. 委托：如果未加载（缓存）某个类，则将该请求委托给其父级。这一直持续到层次结构的顶部（ 引导 类加载器）加载谁J2SE基本相关类（即Integer，ArrayList除其他）。这是您在问题中引用的内容： 类加载器将加载委派到层次结构的顶部，然后，如果某个类加载器的父级找不到它，则每个类加载器都会尝试加载该类，直到有人加载它为止。 否则：ClassNotFound。
2. 可见性：父类加载器加载的类对其子级可见，而反之则不可见。
3. 唯一性：如果父类加载器加载了一个类，则子类将永远不会重新加载它。

在Java SE中，类加载器将类加载委托给其父类加载器，然后尝试加载类本身。

没错，由于上述原理。

J2EE中没有确定的类加载器结构（供应商拥有“诗意的许可证”来实现它），但是他们有点遵循层次结构。在这种情况下， 系统类路径
类加载器将加载主应用程序：服务器。然后，由于 可见性原则 ，每个应用程序都可以使用服务器库（更具体地说是其类）。

在那儿，这些应用程序具有特定的类加载器结构，但总体而言，它们是 System-classpath类加载器的 不同 子 类
。每个应用程序都加载其相关和特定的类（应用程序和库）。

此处的负载不会传播到应用程序上下文之外的父级。为什么？因为如果 System-classpath类
加载器像往常一样加载应用程序，则由于可见性原理，每个应用程序的类对其他用户都是可见的，从而完全打破了它们之间的隔离。所以：

但是，在Java EE中，类加载器首先尝试加载类本身，然后将该类的类加载委托给其父类加载器。

这在一定程度上是正确的，但是我宁愿将此确认限制在应用程序的上下文中，而忽略了Java相关类，这些类确实是由顶级类加载器加载的。

长话短说：这不是一个简单的过程，但是我不会说J2EE处理与J2SE相反的类加载。