JVM启动后Java类路径是最终的吗？

Question

我最近读了很多关于Java类加载过程的文章。我经常遇到一些文本，声称在运行时将类添加到类路径并在没有类加载器黑客（URLClassLoaders 等）的情况下加载它们是不可能的。

据我所知，类是动态加载的。这意味着它们的字节码表示仅在需要时加载并转换为 java.lang.Class 对象。

那么，是否可以在 JVM 启动后将 JAR 或 *.class 文件添加到类路径并加载这些类（前提是它们尚未加载）？ （需要明确的是：在这种情况下，类路径只是文件系统上的文件夹。“添加 JAR 或 *.class 文件”只是意味着将它们放入此文件夹中。）

如果没有，这是否意味着在 JVM 上搜索类路径启动和找到的类的所有完全限定名称都缓存在内部“列表”中？

如果您能在您的答案中向我指出一些来源，那就太好了。最好是 SUN 官方文档：Sun JVM Spec 。我已阅读规范，但找不到有关类路径的任何内容以及它是否在 JVM 启动时完成。

Ps

这是一个理论问题。我只是想知道是否可能。我没有什么想要实现的实际目标。这只是我对知识的渴望:)

Answer 1

这里有两个概念被混合在一起：类路径和类路径中的类文件。

如果将类路径指向一个目录，那么将文件添加到该目录并将其作为类路径的一部分拾取通常不会有任何问题。由于类路径中所有类的潜在大小，现代 JVM 在启动时加载所有类实际上是不可行的。然而，这价值有限，因为它不包含 Jar 文件。

然而，在运行的 JVM 上更改类路径本身（搜索哪些目录、jar 等）将在很大程度上取决于实现。据我所知，在标准 Sun JVM 上，没有记录的（保证有效的）方法来完成此操作。

一般来说，如果这是您需要做的事情（有一个在运行时更改的动态类路径），那么您希望实现一个类加载器，如果没有其他原因，除了能够扔掉它并创建一个新的类加载器之外，如果需要卸载这些类，则不再引用它们。

然而，对于少量的动态加载，有更好的方法。在 Java 1.6 中，您可以指定目录 (*.jar) 中的所有 jar 文件，以便您可以告诉用户将其他库放在指定位置（尽管它们在启动时必须位于该位置）。

您还可以选择在类路径中包含 jar 文件或其他位置，即使您不需要它，作为某人在其中放置可选 jar 或资源文件（例如日志配置文件）的占位符。

但是，如果您需要严格的动态类加载，尤其是在应用程序运行时卸载，则需要 Classloader 实现。

Answer 2

由于没有人能给我明确的答案，也没有人能给我提供文档相应部分的链接，所以我自己提供了一个答案。尽管如此，我还是要感谢所有试图回答这个问题的人。

简短的回答：

类路径在 JVM 启动时不是最终的。

实际上，您可以在 JVM 启动后将类放入类路径中，并且它们将被加载。

---

长答案：

为了回答这个问题，我遵循了用户未知建议并编写了一个小测试程序。

基本思想是有两个类。第一个类是实例化第二个类的主类。启动时，第二个类不在类路径上。 cli 程序启动后，它会提示您按 Enter 键。在按 Enter 键之前，请复制类路径上的第二个类。按 Enter 键后，第二个类将被实例化。如果类路径在 JVM 启动时是最终的，则会抛出异常。但事实并非如此。所以我假设 JVM 启动时类路径不是最终的。

以下是源代码：

JVMTest.java

package jvmtest;

import java.io.Console;
import jvmtest.MyClass;

public class JVMTest {
  public static void main(String[] args) {
    System.out.println("JVMTest started ...");

    Console c = System.console();
    String enter = c.readLine("Press Enter to proceed");
    MyClass myClass = new MyClass();
    System.out.println("Bye Bye");
  }
}

MyClass.java

package jvmtest;

public class MyClass {
  public MyClass() {
    System.out.println("MyClass v2");
  }
}

文件夹结构如下所示：

jvmtest/
  JVMTest.class
  MyClass.class

我使用以下命令启动了 cli 程序：

> java -cp /tmp/ jvmtest.JVMTest

如您所见，我的 jvmtest 文件夹位于 /tmp/jvmtest 中。显然，您必须根据放置类的位置来更改此设置。

以下是我执行的步骤：

1. 确保 jvmtest 中只有 JVMTest.class。
2. 使用上面的命令启动程序。
3. 只是为了确保按 Enter 键。您应该看到一个异常，告诉您找不到类。
4. 现在再次启动该程序。
5. 程序启动后，系统会提示您按 Enter 键，将 MyClass 文件复制到 jvmtest 文件夹中。
6. 按回车键。您应该看到“MyClass v1”。

附加说明：

当我将 MyClass 类打包到 jar 中并运行上面的测试时，这也有效。

我在运行 Mac OS X 10.6.3 的 Macbook Pro 上运行此命令，

> Java -version

结果如下：

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)

Answer 3

@Jen我不认为你的实验可以证明你的理论，因为它更多的是关于对象实例化：当实例化此类的对象时，你的打印行就会发生，但不一定告诉JVM知道你的代码，类，就在它发生的时候正在实例化。

我的观点是，所有的Java类都是在JVM启动时加载的，并且可以在JVM运行时将更多的类插入到JVM中：这种技术称为：热部署。

Answer 4

底线：可以在运行时向系统类路径添加条目，并显示了如何操作。然而，这具有不可逆的副作用，并且依赖于 Sun JVM 实现细节。

---

类路径是 final，从最字面的意义上来说：< /em>

系统类加载器（从主类路径加载的类加载器）是 sun rt.jar中的 .misc.Launcher$AppClassLoader。

rt.jar:sun/misc/Launcher.class （源代码是使用 Java Decompiler):

public class Launcher
{
 <...>
 static class AppClassLoader
    extends URLClassLoader
  {
    final URLClassPath ucp = SharedSecrets.getJavaNetAccess().getURLClassPath(this);
<...>

rt.jar:sun/misc/URLClassLoader.class:

protected Class<?> findClass(final String paramString)
    throws ClassNotFoundException
  {
    <...>
          String str = paramString.replace('.', '/').concat(".class");
          Resource localResource = URLClassLoader.this.ucp.getResource(str, false);
  <...>

但是，即使该字段是最终的，这并不意味着我们不能改变对象本身，如果我们以某种方式访问它。该字段没有访问修饰符 - 这意味着，只要我们从同一个包进行调用，我们就可以访问它。 （以下是 IPython 和 JPype；这些命令具有足够的可读性，可以轻松导出其 Java 对应项）

#jpype doesn't automatically add top-level packages except `java' and `javax'
In [28]: jpype.sun=jpype._jpackage.JPackage("sun")

In [32]: jpype.sun.misc.Launcher
Out[32]: jpype._jclass.sun.misc.Launcher

In [35]: jpype.sun.misc.Launcher.getLauncher().getClassLoader()
Out[35]: <jpype._jclass.sun.misc.Launcher$AppClassLoader at 0x19e23b0>    

In [36]: acl=_

In [37]: acl.ucp
Out[37]: <jpype._jclass.sun.misc.URLClassPath at 0x19e2c90>

In [48]: [u.toString() for u in acl.ucp.getURLs()]
Out[48]: [u'file:/C:/Documents%20and%20Settings/User/']

现在，URLClassPath 有一个公共 addURL 方法。让我们尝试一下，看看会发生什么：

#normally, this is done with Launcher.getFileURL but we can't call it directly
#public static URLClassPath.pathToURLs also does the same, but it returns an array
In [72]: jpype.sun.net.www.ParseUtil.fileToEncodedURL(
             jpype.java.io.File(r"c:\Ivan\downloads\dom4j-2.0.0-RC1.jar")
             .getCanonicalFile())
Out[72]: <jpype._jclass.java.net.URL at 0x1a04b50>

In [73]: _.toString()
Out[73]: u'file:/C:/Ivan/downloads/dom4j-2.0.0-RC1.jar'

In [74]: acl.ucp.addURL(_72)

In [75]: [u.toString() for u in acl.ucp.getURLs()]
Out[75]:
[u'file:/C:/Documents%20and%20Settings/User/',
 u'file:/C:/Ivan/downloads/dom4j-2.0.0-RC1.jar']

现在，让我们尝试从 .jar 加载一些类：

In [78]: jpype.org=jpype._jpackage.JPackage("org")

In [79]: jpype.org.dom4j.Entity
Out[79]: jpype._jclass.org.dom4j.Entity 

成功！

这可能会在沙箱或存在自定义类加载器或安全设置的情况下失败（AppClassLoader.loadClass 在调用 super 之前进行安全检查）。

进一步的代码检查显示，addURL 还禁用了 URLClassPath 的查找缓存（在一些 native 方法中实现），并且这是不可逆的。最初，lookupCacheEnabled 标志设置为 sun.cds.enableSharedLookupCache 系统属性的值。

该界面不提供编辑条目的方法。 URL 将添加到 URLClassPath 的 私有 ArrayList 路径 和 Stack url 中。 urls 是可访问的，但事实证明，它仅在尝试从中加载之前临时保存条目，此时信息将移动到 HashMap lmap 和 ArrayList 加载器。 getURLs() 返回path 的副本。因此，理论上可以通过破解可访问字段来编辑它，但它远不可靠，并且不会影响 getURLs 结果。

Answer 5

我只能根据我自己十年前破解非 Sun JVM 的经验来发表评论，但它确实在启动时扫描了整个类路径，作为一种效率衡量标准。找到的所有类的名称及其位置（目录或 zip/jar 文件）都添加到内部哈希表中。然而，那是十年前的事了，我不禁想知道，考虑到磁盘和内存架构的演变，在大多数设置中这是否仍然是合理的事情。

Answer 6

我相信类路径被视为静态的，并且更改文件的结果是未定义的。

如果您确实希望能够在运行时添加和删除类，请考虑在您自己的类加载器中执行此操作。这就是 Web 容器的作用。

Answer 7

所以不应该添加一个
JAR 或 *.class 文件添加到类路径
JVM启动后...

您将 jar 和目录添加到类路径，而不是类。这些类位于目录或 jar 中。

如果不是，这是否意味着
JVM 启动时搜索类路径
以及所有完全限定名称
找到的类缓存在
内部“列表”？

这很容易测试：设置类路径，启动程序，将新类移动到 CP 中，从程序中调用 'Class.forName ("NewClass")。它找到新班级了吗？

Answer 8

我想你可以阅读 TomCat 服务器的文档。该服务器通过自己实现java classpath。因此，当该服务器启动时，您可以部署新的 webApp，只需将 jar 拖放到热的适当文件夹中，无需重新启动服务器，它就会上传您的应用程序。