Java EE和Java SE类加载 [英] Java EE and Java SE classloading
问题描述
我在互联网上阅读的Java EE和Java SE类加载之间的区别在于
The difference that I read on the Internet between Java EE and Java SE classloading is that
在Java SE中，类加载器委托类加载到其父
类加载器，然后尝试加载类本身
In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself
但是，在Java EE中，类加载器首先尝试加载类本身然后
将该类的类加载委托给其父类加载器。
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中的设计相同（保持这种优势的任何优点。）
Also, why is it designed like that in Java EE (Any advantages of keeping it like this.)
这是我听到的链接[http://www.youtube.com/watch?v=t8sQw3pGJzM]
This is the link where I heard this [http://www.youtube.com/watch?v=t8sQw3pGJzM]
推荐答案
好吧那么，
一个常见的应用程序有3个标准的类加载器：
A common application has 3 standard classloaders:
- Bootstrap Classloader
- 扩展类加载器
- System-Classpath类加载器
到目前为止，非常好。现在，这适用于单独运行且免费运行的单个应用程序。
So far, so good. Now, this works for a single application running alone and free.
但是当你说 J2EE 时会发生什么？您有多个应用程序在同一个地方运行，因此您必须找到一种方法来阻止它们相互绊倒。这就是这些额外的类加载器发挥作用的地方。
But what happens when you say J2EE? You have multiple applications running on the same place, so you have to figure out a way to prevent them from stumbling on each other. That's where these extra classloaders come into play.
考虑服务器实例。有一个JBoss有两个部署的EAR。如果应用程序之间存在冲突的类会发生什么？他们对自己的特定背景感到满意，但总的来说它们是不一致的。
Think about a server instance. There's a JBoss with two deployed EARs. What would happen if there were to be conflicting classes between applications? They're ok on their own particular context but as a whole they're inconsistent.
这些额外的类加载器是以应用程序方式引入的，以确保确保它们之间的隔离。 System-Classpath Classloader 下面的类加载器只有在其中一个子项的清单文件中指定类时才会识别该类。
These extra classloaders are introduced in an application-wise way to ensure the isolation between them. Classloaders below System-Classpath Classloader recognize a class only if it is specified in the manifest file for one of its childs.
在J2SE中，三个基本的类加载器基于三个原则在父子关系中工作：
In J2SE, the three basic classloaders work in a parent-child relationship based on three principles:
- 委派：如果没有加载类（缓存），请求被委托给其父级。这一直持续到层次结构的顶层（ Bootstrap 类加载器）加载基本的J2SE相关类（即
Integer，ArrayList，等等）。这是您在问题中引用的内容：类加载器将加载委托给层次结构的顶部，然后每个类加载器尝试加载该类，如果其父级无法找到它，直到有人加载它。否则：ClassNotFound。 - 可见性：父类加载器加载的类对其子项是可见的，而不是相反。
- 唯一性：如果父类加载器加载一个类，子项永远不会重新加载它。
- Delegation: If a class is not loaded (cache), the request is delegated to its parent. This goes on until the top of the hierarchy (Bootstrap classloader) who loads basic J2SE related classes (i.e.
Integer,ArrayList, amongst others). This is what you reference in your question: A classloader delegates the loading until the top of the hierarchy, then each classloader tries to load the class if its parent couldn't find it, until someone loads it. Otherwise: ClassNotFound. - Visibility: Classes loaded by a parent classloader are visible to its children, not the other way around.
- Uniqueness: If a parent classloader loads a class, a children will never reload it.
在Java SE中，类加载器将类加载委托给其父类加载器，然后尝试加载类本身。
In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself.
是的，由于上面解释的原则。
True, due to the principles explained above.
J2EE中没有确定的类加载器结构（供应商有诗歌许可来实现它），但它们遵循层次结构。在这种情况下， System-classpath 类加载器加载主应用程序：服务器。由于可见性原则，服务器库（更具体地说是其类）可用于每个应用程序。
There's no determined classloader structure in J2EE (a vendor has "poetic license" to implement it), but they kind of follow a hierarchy. In this case, the System-classpath classloader loads the main application: The server. The server libraries (its classes, more specifically) are available, then, to every application due to the visibility principle.
在那里，应用程序具有特定的类加载器结构，但作为一个整体，它们是 System-classpath类加载器的不同子项。每个应用程序加载其相关的和特定的类（应用程序和库）。
Down there, the applications have particular classloader structures, but as a whole they are different children of the System-classpath classloader. Each application loads its related and particular classes (both application and libraries).
此处的加载不会传播到应用程序上下文之外的父项。为什么？因为如果 System-classpath 类加载器像往常一样加载应用程序，由于可见性原则，每个应用程序的类对其他应用程序都是可见的，完全打破了它们之间的隔离。所以：
The loading here is not propagated to the parents outside the application context. Why? because if the System-classpath classloader were to load the applications as usual, the class of every application would be visible to others due to the visibility principle, completely breaking the isolation between themselves. So:
但是，在Java EE中，类加载器首先尝试加载类本身，然后将该类的类加载委托给其父类classloader。
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相关这些类确实由顶级类加载器加载。
This is partly true, but I'd rather limit this affirmation to the context of an application and leave out the Java related classes, that are indeed loaded by the top level classloaders.
长话短说：这不是一个简单的过程，但我不会说J2EE处理类加载J2SE的相反方式。
Long story short: It's not a straightforward process but I wouldn't go as far as to say J2EE handles the classloading the opposite way around of J2SE.
这篇关于Java EE和Java SE类加载的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
