Java转换会带来开销吗？为什么？

Question

当我们将一种类型的对象转换为另一种类型时，会产生额外的开销吗？还是编译器可以解决所有问题，并且在运行时没有成本？这是一般的事情，还是有不同的情况？例如，假设我们有一个Object []数组，其中每个元素可能具有不同的类型。但是我们始终可以肯定地知道，例如，元素0是Double，元素1是String。（我知道这是一个错误的设计，但是让我们假设我必须这样做。）Java的类型信息是否仍在运行时保留？还是编译后一切都被遗忘了，如果我们执行（Double）elements [0]，我们将仅跟随指针并将这8个字节解释为双精度，无论是什么？我不清楚在Java中如何完成类型。如果您对书籍或文章有任何建议，也请多谢。

Answer 1

有2种类型的转换：

隐式转换，当您将类型从类型转换为更宽泛的类型时，它是自动完成的，并且没有开销：

String s = "Cast";

Object o = s; // implicit casting

从较宽的类型转换为较窄的类型时，显式转换。对于这种情况，您必须显式使用如下所示的强制转换：

Object o = someObject;

String s = (String) o; // explicit casting

在第二种情况下，运行时会产生开销，因为必须检查这两种类型，并且在强制转换不可行的情况下，JVM必须抛出ClassCastException。

摘自JavaWorld：铸造成本

铸造用类型之间的转换-特别是引用类型之间，铸造操作中，我们有兴趣在这里的类型。

上位操作（在Java语言规范中也称为扩展转换）将子类引用转换为祖先类引用。这种转换操作通常是自动的，因为它总是安全的，并且可以由编译器直接实现。

向下转换操作（在Java语言规范中也称为缩小转换）将祖先类引用转换为子类引用。由于Java要求在运行时检查强制转换以确保其有效，因此此强制转换操作会产生执行开销。如果引用的对象不是强制转换的目标类型的实例或该类型的子类的实例，则不允许尝试进行强制转换，并且必须抛出java.lang.ClassCastException。

Answer 2

对于Java的合理实现：

每个对象都有一个标头，除其他外，标头包含一个指向运行时类型的指针（例如Double或String，但永远不能是CharSequence或AbstractList）。假设运行时编译器（在Sun情况下通常为HotSpot）无法静态确定类型，则生成的机器代码需要执行一些检查。

首先，需要读取指向运行时类型的指针。无论如何，这对于在类似情况下调用虚拟方法是必需的。

对于强制转换为类类型，在您命中之前java.lang.Object，确切知道有多少个超类，因此可以从类型指针（实际上是HotSpot中的前八个）以恒定的偏移量读取类型。同样，这类似于读取虚拟方法的方法指针。

然后，读取值仅需要与预期的强制类型转换进行比较。根据指令集的体系结构，另一条指令将需要在错误的分支上分支（或出错）。诸如32位ARM之类的ISA具有条件指令，并且可能能够使悲伤路径通过快乐路径。

由于接口的多重继承，接口更加困难。通常，对接口的最后两个强制类型转换将在运行时类型中进行缓存。在早期（十多年前），接口有点慢，但这已不再重要。

希望您能看到这种情况与性能无关。您的源代码更为重要。在性能方面，您的方案受到的最大打击可能是由于在各处跟踪对象指针而导致的高速缓存未命中（类型信息当然很常见）。

Answer 3

例如，假设我们有一个Object []数组，其中每个元素可能具有不同的类型。但是我们始终可以肯定地知道，例如，元素0是Double，元素1是String。（我知道这是一个错误的设计，但是让我们假设我必须这样做。）

编译器不会记录数组中各个元素的类型。它只是检查每个元素表达式的类型是否可分配给数组元素类型。

Java的类型信息是否仍在运行时保留？还是编译后一切都被遗忘了，如果我们执行（Double）elements [0]，我们将仅跟随指针并将这8个字节解释为双精度，无论是什么？

在运行时会保留一些信息，但不会保留各个元素的静态类型。您可以通过查看类文件格式来说明这一点。

从理论上讲，JIT编译器可以使用“转义分析”来消除某些分配中不必要的类型检查。但是，按照您建议的程度执行此操作将超出实际优化的范围。分析单个元素类型的收益将太小。

此外，人们不应该这样写应用程序代码。