这与提问有点相同:是否存在子类/超类基元类型的任何内容?
(因为((Object) (new String[6])) instanceof Object[]
为真,因为String extends Object
。)
例如,在int[]
中, ONLY ((Object) (new int[3])) instanceof int[]
是否属于Java中的任何内容?
如果是的话,
((Object) (new int[3])) instanceof int[]
与
相同((Object) (new int[3])).getClass() == int[].class
我更喜欢后者,因为它应该更快,因为它不必检查每个类型/类的继承。
答案 0 :(得分:5)
确实很难理解你在问什么,但我想你是在问:使用getClass()
比使用instanceof
对数组类型更好。
从可读性的角度来看,instanceof
更好:
Object obj = new int[3];
if (obj instanceof int[]) {
int[] array = (int[]) obj;
}
if (foo.getClass() == int[].class) {
int[] array = (int[]) obj;
}
显然,第一种形式更具可读性。
从性能角度来看,我无法理解为什么两个版本可能不相同。在instanceof
情况下,int[]
类型没有子类型,因此可以将其编译为等同于或甚至可能比 getClass()
更快的内容版本
确定哪个实际上更快的唯一方法是编写一个不错的微基准测试并在您感兴趣的平台上运行它。请注意,您可能会针对不同版本的Java获得不同的性能结果
但是,我强烈怀疑性能差异太小,不会对您的应用程序产生任何影响。除非你已经具有指出这个瓶颈的具体分析结果......否则你可能会浪费你的时间。
这在某种程度上与询问相同:是否存在子类/超类基元类型的任何内容?
没有。这完全不等于要求。 Java数组类型不是基本类型。它们是参考类型。
然而,它与数组类型之间是否存在子类型关系的问题有关。或者更准确一点,它归结为您是否可以从一种数组类型转换为另一种数组类型。
它的答案取决于基本类型;见JLS 5.5.1. Reference Type Casting。如果基类型是(不同的)基本类型,则答案为否。如果基类型是引用类型,那么如果可以从一种基类型(BC1
)转换为另一种基类型(BC2
),那么涉及数组类型(BC1[]
到{{}的转换1}})也是合法的。
因此,这意味着BC2[]
和instanceof
测试将为基本数组类型提供相同的答案,但不是针对所有数组类型。
事实上,在原始Java语言设计中,允许在不同数组类型之间进行任何转换可能是一个错误。这会导致异常,例如:
getClass()
答案 1 :(得分:1)
(B的实例)当A“isa”B时返回true,或者当你可以使用A时预期B。 使用==对类对象或类名进行的任何比较都将比较身份。如果您需要知道A和B是完全相同的类型,您可以使用A.getClass()== B.getClass()。 原始类型不从Object继承,但是数组可以继承。例如,您可以说
if(new int[2] instanceof Object)
但不是
if(new int[2] instanceof Object[])
后者不会编译
在面向对象编程中,您通常关心等价而不是精确类型。我认为你几乎总是想要测试适用性(使用instanceof)而不是身份(使用==)。
请注意,不需要转换为Object。
if(new String[2] instanceof Object[])
System.out.println("true");
答案 2 :(得分:0)
Java不是纯粹的OO编程语言,因为有原始数据类型。
问:是否有任何子类/超类基元类型?
答:不,原语没有超类的子类,它只是原始类型。
Java中的数组是对象类型,它的内容是否是基本类型的对象类型,所以如下 陈述是真的:
System.out.println("Is int[] instance of Object:"+(intArray instanceof Object));
System.out.println("The type of int[] is:"+(intArray instanceof int[]));
System.out.println("Is the class of intArray equal to int[]:"+
(intArray.getClass()==int[].class));
问:我更喜欢后者,因为它不应该更快,因为它不必检查每个类型/类的继承。
答:不,没有证据证明这一点。即使它是真的,它在Java中也不是问题,因为效率并不总是我们的考虑