Java ClassLoader和依赖关系解析 [英] Java ClassLoader and Dependency Resolution

问题描述

有人可以澄清ClassLoader的作用不仅是加载单个类，而且还加载其依赖项?如果是这样，那么整个过程到底需要什么呢?我正在寻找所有可能的实现细节.

Can someone clarify that the role of a ClassLoader is not only to load an individual class, but also its dependencies? And if so, what exactly does the entire process entail? I'm looking for implementation detail if at all possible.

例如，在某些时候，必须从某个位置(网络或文件系统位置)读取字节，并且必须根据类的规范名称和文件名来计算文件系统位置. JVM可用的类路径的预知-单个ClassLoader如何尝试在潜在的多个类路径上定位文件?它从何处获得此信息?另外，什么时候验证了类文件的字节并检查了其依赖项的可用性?

For example, at some point, bytes are going to have to be read in from somewhere (a network or filesystem location), and file system locations are going to have to be calculated on the basis of a classes canonical name and a foreknowledge of class paths available to the JVM- how does an individual ClassLoader try to locate a file over potentially multiple class-paths? Where does it get this information from? Also, at what point are a class files bytes verified and its dependencies examined for availability?

尽可能多的细节将不胜感激:)

As much detail as possible would be appreciated :)

推荐答案

ClassLoading是一个非常复杂的主题. ClassLoader和Java安全模型紧密地联系在一起.本质上，JVM按需加载类.当有一个类加载器的层次结构时，JVM会尝试尽可能在链的最下方解析该类.简而言之，如果在启动"类加载器中定义了该类，并且在应用程序定义的类加载器中定义了该类，则它将始终在启动类加载器中使用该版本.

ClassLoading is a very complex subject. The ClassLoader and Java security model are inextricably tied together. Essentially the JVM loads classes on demand. When there is a hierarchy of classloaders, the JVM attempts to resolve the class as far down the chain as possible. In short, if the class is defined in the "boot" classloader and in an application defined class loader, it will always use the version in the boot classloader.

在类加载器(例如URLClassLoader)中，搜索顺序是您告诉它的外观顺序.从本质上说，您将告知从中检索到具有类的URL数组，从第一个条目到最后一个条目.

Within a classloader, such as the URLClassLoader, the search order is the order in which you've told it to look. Essentially the array of URLs you told it had classes will be searched from the first entry to the last.

当您定义的类引用另一个类时，也可以使用相同的算法来解析该类.但是这里有个问题:它只能相对于找到它的位置来解决它.让我们来考虑这样一个场景，其中类SomeCoolThing在引导类加载器中，但是依赖于SomeLameThing，后者在应用程序定义的类加载器中.该过程将如下所示:

When the class that you defined references another class, that class is also resolved using the same algorithm. But here's the catch: it only resolves it relative to where it was found. Let's take the scenario where the class SomeCoolThing is in the boot classloader, but depends on SomeLameThing, which is in an application defined classloader. The process would look like this:

App-ClassLoader: resolveClass("SomeCoolThing")
    parent->resolveClass("SomeCoolThing")

Boot-ClassLoader (the ultimate parent): resolveClass("SomeCoolThing")
    SomeCoolThing needs SomeLameThing
    resolveClass("SomeLameThing") // Can't find SomeLameThing!!!!

即使SomeLameThing在您请求SomeCoolThing的类加载器中，SomeCoolThing仍在其他类加载器中解决.该其他类加载器不了解子类加载器，并尝试自行解决，但失败.

Even though SomeLameThing is in the classloader where you requested SomeCoolThing, SomeCoolThing was resolved in a different classloader. That other classloader has no knowledge of the child classloader, and tries to resolve it itself and fails.

很久以前，我有一本书非常深入地介绍了Java ClassLoader，所以我推荐它.它是 O'Reilly Media提供的Java安全性.在处理ClassLoader及其工作方式时，它将回答您从未想过但仍然需要知道的每个问题.

I had a book a long time ago that covered the Java ClassLoaders in really good depth, and I recommend it. It's Java Security by O'Reilly Media. It will answer every question you never wanted to know, but still need to, when dealing with ClassLoaders and how they work.

这篇关于Java ClassLoader和依赖关系解析的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！