Java EE 和 Java SE 类加载

Question

我在 Internet 上看到的 Java EE 和 Java SE 类加载的区别是

In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself

However, In Java EE, a classloader first tries to load the class itself and then delegate the classloading of that class to its parent classloader.

请验证我的理解。

此外，为什么它在 Java EE 中设计成这样(保持这样的任何优点。)

这是我听到这个 [http://www.youtube.com/watch?v=t8sQw3pGJzM] 的链接

Answer 1

那好吧

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

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

到目前为止，还不错。现在，这适用于单独免费运行的单个应用程序。

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

考虑一个服务器实例。有一个带有两个已部署 EAR 的 JBoss。如果应用程序之间存在冲突的类，会发生什么情况？他们在自己的特定背景下还可以，但作为一个整体，他们是不一致的。

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

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

1. 委派:如果一个类没有被加载(缓存)，请求被委派给它的父类。这一直持续到层次结构的顶部(Bootstrap 类加载器)加载基本的 J2SE 相关类(即 Integer、ArrayList 等)。这就是您在问题中引用的内容:类加载器将加载委托(delegate)到层次结构的顶部，然后每个类加载器在其父类找不到它时尝试加载该类，直到有人加载它。否则:ClassNotFound。
2. 可见性:父类加载器加载的类对其子类可见，反之则不然。
3. 唯一性:如果父类加载器加载了一个类，子类将永远不会重新加载它。

In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself.

没错，根据上面解释的原则。

J2EE 中没有确定的类加载器结构(供应商有“诗意的许可”来实现它)，但它们有点遵循层次结构。在这种情况下，System-classpath 类加载器加载主应用程序:服务器。由于可见性原则，服务器库(更具体地说，它的类)对于每个应用程序都是可用的。

在那里，应用程序具有特定的类加载器结构，但作为一个整体，它们是系统类路径类加载器的不同子级。每个应用程序加载其相关的和特定的类(应用程序和库)。

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

However, In Java EE, a classloader first tries to load the class itself and then delegate the classloading of that class to its parent classloader.

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

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