反射是针对类加载器的吗？

Question

我知道反射是一种在不知道具体类型的情况下调用方法或操作字节码的技术。

最近，在研究类加载器时，我遇到了一篇文章:反射是让类加载器动态加载类并进行类型检查。这是真的吗？

文章

原文不是英文的，所以翻译可能有点奇怪。

动态加载类。也就是说，所有代码都在运行时链接到JVM。每个类都动态地链接到JVM，并在引用该类时加载到内存中。Java的运行时库(JDK安装目录/jre/lib/rt.jar)也不例外。这种动态的类加载是通过Java的类加载器系统来完成的，由Java提供的类加载器是通过java.lang.ClassLoader来表示的。JVM启动时，它会创建一个引导类装入器，然后将第一个类Object读入系统。

在运行时动态加载类意味着JVM没有该类的信息。换句话说，JVM不知道有关类的方法、字段和继承关系的信息。因此，类加载器应该能够在加载类时获得必要的信息，并检查类是否正确。如果您不能这样做，JVM可能有与.class文件不匹配的版本，并且不可能进行类型检查。JVM具有内部分析类的能力，在JDK1.1中，开发人员可以通过反射来分析这些类。

Answer 1

这一引文中的任何内容都不能得出这样的结论:反射是“类加载器”。

文本以“…”结尾在JDK1.1中，开发人员可以通过反射来分析这些类。反射是代表自身的额外信息。这篇文章之前提到过的类加载器，在这里没有任何意义。

提到版本号时，它归结为“实际上从一开始”，表明这是一个相当古老的文本。这就解释了

因此，

类加载器应该能够在加载类时获得必要的信息，并检查类是否正确。

类加载器根本不这样做。但是在Java1.0和部分Java1.1中，类加载器确实被认为负责链接和验证任务。从那时起，类装入器的职责仅限于定位必要的资源并将其加载到一个字节数组中，然后传递给JVM。链接和验证是JVM的工作，这意味着它还将保护自己免受潜在的类加载器的破坏。

由于类加载器的工作只是将文件、套接字或其他资源读入字节数组并将它们传递给JVM，因此它们本身不需要任何反射API。

Answer 2

反射是Java代码检查已经加载的Java类并与它们动态交互的能力(也就是说，不仅仅是调用编译时已经知道的方法或访问字段)。

JVM在加载类时所做的类似之处在于，它检查字节码以了解构成类的部分并检查其正确性，但这并不是上面所写的意义上的反映:它不使用相同的API，因为它们仅限于较高级别的视图。实际上，Java中的反射API只有在JVM已经充分分析和“理解”了类之后才起作用。

注意，类加载器本身实际上不需要理解类:它只向JVM提供原始字节码来加载它们。它所要做的就是定位字节码并将其加载到内存中。

Answer 3

是反射是用于类加载器的吗？

基本上..。不是的。

大多数类加载器Java代码都是关于在类路径上查找类和资源。当它决定需要加载一个类时，它会调用一个内部的本机方法来将包含类文件表示的byte[]或ByteBuffer转换为一个加载的类。本机方法使用的基础设施位于常规Java代码使用的反射API之下。

另一方面，应用程序在许多方面使用反射，所以即使类加载器确实使用反射，也不能说反射是针对类加载器的。是为了..。很多事情。

反射是个有点像橡胶的词..。但一般的想法是，它是关于一个程序，看或思考自己。在这种情况下，JVM不是程序。运行程序的是机器。类加载和维护运行时类型安全是JVM的基本功能。反射API是JVM提供给运行在JVM上/在JVM中运行的(Java等)应用程序的服务。

还有..。

我知道反射是一种.操纵字节码..。

实际上，反射不允许你“操纵”传统意义上的字节码。这种事情(所谓的“字节码工程”)是由另一种图书馆完成的。它发生在字节码加载之前。

这是有点难以理解什么引文实际上是说，尤其是因为翻译。但我认为这并不是说类加载器需要使用反射。

因此，

类加载器应该能够在加载类时获得必要的信息，并检查类是否正确。

对，是这样。

如果您不能这样做，

可能会出现与.class文件不匹配的版本，因此不可能进行类型检查。

对，是这样。

具有内部分析类的能力，

对，是这样。但是它并没有说JVM正在使用反射来完成这个任务。它正在使用(未指定的)内部机制。它们不涉及对反射API的调用。即使在Java1.0/ 1.1天，当ClassLoader类负责链接和验证(根据@Holger的回答)，他们也会直接解析类文件，而不是使用反射API。

和JDK1.1中，开发人员可以通过反射来分析这些类。

这有点不合理.但是我认为正确的阅读方法是开发人员也可以访问类型信息。这并不是说类加载器和Java程序使用相同的(反射)API来访问类型信息。

总之，我认为你误解了这篇文章的意思。