Java类加载器:为什么首先搜索父类加载器？

Question

Java中类加载器的正确行为是：

1. 如果它已经加载，则返回类。
2. 调用父loadClass()
3. 尝试加载类本身。

因此，系统类路径中定义的类应该始终先加载。Tomcat为每个war定义了类加载器，它将系统类加载器作为父类，因此如果您试图加载一个类，它将首先查看系统类路径，然后查看war文件中定义的类路径。

根据我的理解，这有两个原因：

1. 以避免使用不同版本的类的问题。假设我在一场战争中重新定义了java.lang.Object，那将是一场噩梦。
2. 为了避免对子类加载器的依赖:系统类加载器不能依赖子类加载程序:例如，很难重新部署war。

因此，问题是：

除了上述问题之外，实现不首先执行父级搜索的类加载器还有其他缺陷吗？

Answer 1

Tomcat不首先查找父类加载程序。实际上，情况正好相反:它首先在webapp中查找，然后才转到父类加载程序( Tomcat 6/7的"lib“，Tomcat 5.5的”共享“)。这个规则的例外是系统类(我认为所有包含java.*和javax.*包的东西)，这些类只在系统类加载器中查看。我相信他们这么做的原因就是你说的第一条理由。

所以从根本上讲，实施父母第一战略是可以的。它也可以实现父母-最后。这两种策略都有各自的优缺点。

我将再给出一个原因，为什么要实现父级--首先:减少perm内存中加载的类的数量。假设您有多个web应用程序使用相同的库。使用父库-首先加载一次的库。与父-最后，它将被加载多次。

然而，对于父应用程序--首先是所有的web应用程序--将需要使用相同版本的库，而对于父应用程序，它们可能使用不同的版本。

Answer 2

不怎么有意思。实际上，它只需实例化一个URLClassLoader并为父类提供null：

myClassLoader = new URLClassLoader(myUrlArray, null);

http://download.oracle.com/javase/6/docs/api/java/net/URLClassLoader.html

Answer 3

我能想到的唯一其他原因是确保类路径按预期工作。首先搜索父类，实际上是将父类路径(即系统类路径)放在子类路径之前。因此，如果您在使用-cp启动jvm时指定了特定的jars，那么它们将“隐藏”您试图加载的任何存档中包含的任何jars。如果不首先检查父类，那么子类路径将隐藏父类。