为什么Java API使用int而不是short或byte？ [英] Why does the Java API use int instead of short or byte?

问题描述

当 short 甚至 byte 就足够了？

示例： DAY_OF_WEEK 字段 日历 使用 int 。

如果差异太小，那么为什么这些数据类型（ short ， int ）是否存在？

If the difference is too minimal, then why do those datatypes (short, int) exist at all?

推荐答案

部分原因已经指出。例如， ......（几乎所有）对byte，short的所有操作都会将这些原语提升为int 。然而，显而易见的下一个问题是：为什么这些类型被提升为 int ？

Some of the reasons have already been pointed out. For example, the fact that "...(Almost) All operations on byte, short will promote these primitives to int". However, the obvious next question would be: WHY are these types promoted to int?

更深入一层：答案可能只与Java虚拟机指令集有关。如表中所述Java虚拟机规范，所有整数算术运算，如添加，除法等，仅适用于 int 类型和键入 long ，不表示较小的类型。

So to go one level deeper: The answer may simply be related to the Java Virtual Machine Instruction Set. As summarized in the Table in the Java Virtual Machine Specification, all integral arithmetic operations, like adding, dividing and others, are only available for the type int and the type long, and not for the smaller types.

_{（旁边：较小的类型（ byte 和 short ）基本上只适用于数组。数组，如 new byte [1000] 将采取1000字节，像 new int [1000] 这样的数组将需要4000字节）}

_{(An aside: The smaller types (byte and short) are basically only intended for arrays. An array like new byte[1000] will take 1000 bytes, and an array like new int[1000] will take 4000 bytes)}

现在当然，可以说......显而易见的下一个问题是：为什么这些说明仅适用于 int （和长）？。

Now, of course, one could say that "...the obvious next question would be: WHY are these instructions only offered for int (and long)?".

上面提到的JVM规范中提到了一个原因：

One reason is mentioned in the JVM Spec mentioned above:

如果每个类型化指令支持所有Java虚拟机的运行时数据类型，会有更多的指令，而不是在一个字节中表示

If each typed instruction supported all of the Java Virtual Machine's run-time data types, there would be more instructions than could be represented in a byte

此外，Java虚拟机可以被视为真实处理器的抽象。为较小的类型引入专用的算术逻辑单元是不值得的：它需要额外的晶体管，但它仍然只能在一个时钟周期内执行一次加法。设计JVM时的主要架构是32位，恰好适用于32位 int 。 （涉及64位 long 值的操作是作为特殊情况实现的）。

Additionally, the Java Virtual Machine can be considered as an abstraction of a real processor. And introducing dedicated Arithmetic Logic Unit for smaller types would not be worth the effort: It would need additional transistors, but it still could only execute one addition in one clock cycle. The dominant architecture when the JVM was designed was 32bits, just right for a 32bit int. (The operations that involve a 64bit long value are implemented as a special case).

_{（注意：最后一段有点过于简单，考虑到可能的矢量化等，但应该给出基本的想法，而不要过多地深入处理器设计主题）}

编辑：一个简短的附录，侧重于问题的例子，但更一般意义上：人们还可以问，使用较小的类型存储字段是否有益。例如，有人可能会认为可以通过将 Calendar.DAY_OF_WEEK 存储为字节来保存内存。但是在这里，Java类文件格式发挥作用：所有类文件中的字段占用至少一个槽，其大小为一个 int （32位）。 （宽字段， double 和 long ，占用两个插槽）。因此明确地将字段声明为 short 或 byte 也不会保存任何内存。

A short addendum, focussing on the example from the question, but in an more general sense: One could also ask whether it would not be beneficial to store fields using the smaller types. For example, one might think that memory could be saved by storing Calendar.DAY_OF_WEEK as a byte. But here, the Java Class File Format comes into play: All the Fields in a Class File occupy at least one "slot", which has the size of one int (32 bits). (The "wide" fields, double and long, occupy two slots). So explicitly declaring a field as short or byte would not save any memory either.

这篇关于为什么Java API使用int而不是short或byte？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！