我在互联网上阅读的Java EE和Java SE类加载的区别在于
在Java SE中，类加载器将类加载委托给其父级 classloader然后尝试加载类本身
但是，在Java EE中，类加载器首先尝试加载类本身然后 将该类的类加载委托给其父类加载器。
请确认我的理解。
另外，为什么它的设计与Java EE中的设计相同（保持这种优势的任何优点。）
这是我听到的链接[http://www.youtube.com/watch?v=t8sQw3pGJzM]
答案 0 :(得分：11)
好吧，
一个常见的应用程序有3个标准的类加载器：
到目前为止，这么好。现在，这适用于单独运行且免费运行的单个应用程序。
但是当你说 J2EE 时会发生什么？您有多个应用程序在同一个地方运行，因此您必须找到一种方法来阻止它们相互绊倒。这就是这些额外的类加载器发挥作用的地方。
考虑服务器实例。有一个JBoss有两个部署的EAR。如果应用程序之间存在冲突的类会发生什么？他们对自己的特定背景感到满意，但总的来说它们是不一致的。
这些额外的类加载器以应用程序方式介绍，以确保它们之间的隔离。 System-Classpath Classloader 下面的类加载器仅在类的子文件清单文件中指定时才识别类。
在J2SE中，三个基本的类加载器基于三个原则在父子关系中工作：
Integer，ArrayList等等）。这是您在问题中引用的内容：类加载器将加载委托给层次结构的顶部，然后每个类加载器尝试加载类，如果其父级无法找到它，直到有人加载它。否则：ClassNotFound。 在Java SE中，类加载器将类加载委托给其父类加载器，然后尝试加载类本身。
是的，由于上面解释的原则。
J2EE中没有确定的类加载器结构（供应商有“诗歌许可”来实现它），但它们遵循层次结构。在这种情况下， System-classpath 类加载器加载主应用程序：服务器。由于可见性原则，服务器库（更具体地说，它们的类）可用于每个应用程序。
在那里，应用程序具有特定的类加载器结构，但总体而言，它们是 System-classpath类加载器的不同子项。每个应用程序都加载其相关的特定类（应用程序和库）。
此处的加载不会传播到应用程序上下文之外的父项。为什么？因为如果 System-classpath 类加载器像往常一样加载应用程序，由于可见性原则，每个应用程序的类对其他应用程序都是可见的，完全打破了它们之间的隔离。所以：
但是，在Java EE中，类加载器首先尝试加载类本身，然后将该类的类加载委托给其父类加载器。
这部分是正确的，但我宁愿将这种肯定限制在应用程序的上下文中，而忽略了Java相关的类，这些类确实是由顶级类加载器加载的。
长话短说：这不是一个简单的过程，但我不会说J2EE在J2SE的相反方式处理类加载。
答案 1 :(得分：1)
我认为Java EE class loading standard会帮助你。据我所知，标准Java没有强制的类加载方式。但是，对于WebApps（WAR），指定了类加载是父级的。