Java 64 位 - 整数与短整型

Question

有什么充分的理由在 64 位 JVM 中使用 short 而不是 int 吗？

我的意思是，两者都将占用 32 位分配的内存。

本主题展示了整数如何能够更快地进行乘法等运算:[In java, is it more efficient to use byte or short instead of int and float instead of double?

我还知道基元数组更适合节省分配的内存。

除此之外，在这两种类型之间进行选择时还有什么需要考虑的吗？

Answer 1

tl;博士

除非您有非常特殊的用例，否则只需使用:

• Integer 用于业务对象值、类的成员变量。
• int 用于大量原始数据。

只需使用整数

对于大多数常见的面向业务的 Java 应用程序，常见的做法是仅使用 32 位 int 或 Integer，无需进一步考虑，除非您知道自己会值超过 20 亿，在这种情况下使用 long 或 Long。在现代传统硬件上，没有理由担心使用 short/Short。

特殊情况

但是既然你问“选择时还有什么需要考虑的吗”，这里有三种特殊情况:强制限制、移植 C 代码和替代硬件。

强制执行限制

如果您想强制执行 short 或 Short 的限制，请使用这些类型。当您知道您应该只拥有小于大约 32,000 的值，并且希望编译器或运行时 JVM 强制执行该值时，请选择这些值。

例如，101 加 1:

short oneOhOnePlusOne = ( (short) 101 + (short) 1 ) ;
System.out.println( "oneOhOnePlusOne: " + oneOhOnePlusOne ) ;

102

接下来，尝试超出限制以查看编译器强制执行该限制。

short shortMaxPlusOne = ( Short.MAX_VALUE + (short) 1 ) ;
System.out.println( "shortMaxPlusOne: " + shortMaxPlusOne ) ;

error: incompatible types: possible lossy conversion from int to short

查看此code run live at IdeOne.com .

移植 C 代码

这些不同的数字类型可能被放入 Java 中，以便更容易地移植 C 代码，无论是在实践上还是在心理上都更容易。 Java 的发明者很清楚，在那个时代，大多数新编程语言的尝试都以失败告终，并被批评为“不像 C”。因此Objective-C (Java 的灵感)，因此出现了 C++ 的怪物。 。

因此，事实上，如果您要移植 C 代码，请使用匹配的类型来复制行为。

顺便说一句……从技术上讲，C 并没有实际定义其数字类型的大小。实际上，几乎每个 C 实现都使用 Java 中的大小。

仅供引用，即使是最现代的语言，例如 Swift和 Kotlin具有 8、16、32 和 64 位整数的内置数字类型。

更多限制性硬件

如果您的应用程序有可能在不基于 x86-64 的其他硬件上运行， ，那么您可能想使用这些类型。针对此类硬件的 Java 替代实现可能会针对较小的类型进行更好的优化。

原始与对象

Array of primitives are preferable for saving memory allocated

首先，不要为此感到压力。不要陷入premature optimization的陷阱。在具有大多数常见应用程序的传统硬件上，使用基元与对象、数组与集合相比所节省的内存都是微不足道的。使用适合您的编码上下文的类型(基元/对象)和结构(数组/集合)。

我的做法:

• 在我的代码中，使用对象。
  在我自己的类中仅使用对象(Integer，而不是 int)。我有两个原因。首先，我属于对象迷阵营，他们希望 Java 是纯粹的 OOP，没有任何原语。 (事实上​​，正在进行研究，看看基元是否会在遥远的 future 版本的 Java 中消失。)其次，我发现当我使用基元时，我最终需要在需要上下文的对象中使用它，例如集合。
• 对于其他人的代码，如果他们这样做，请使用原语。
  在我自己的类之外，我不会强制这个问题，因为不适当auto-boxing毫无意义。如果外部代码(不是我自己的)使用原语，我会在该上下文中使用原语。