是否有充分的理由在64位JVM中使用 short 而不是 int ？
我的意思是，两者都将占用32位的内存分配。
本主题说明如何将Integer更快地用于乘法等运算： [In java, is it more efficient to use byte or short instead of int and float instead of double?
我也知道原始数组最好用于节省分配的内存。
除此之外，在这两种类型之间进行选择时还有其他需要考虑的地方吗？
答案 0 :(得分：2)
除非您有非常特殊的用例，否则请使用：
Integer用于表示业务对象值，即类中的成员变量。 int用于处理大量原始数据。 Integer 对于大多数常见的面向业务的Java应用程序，通常的做法是仅使用32位的int或Integer而无需过多考虑，除非您知道自己的价值将超过20亿美元。使用long或Long。在现代常规硬件上，没有理由烦恼使用short / Short。
但是，由于您询问“在选择时还有其他需要考虑的因素”，因此这是三种特殊情况：强制限制，移植C代码和备用硬件。
如果要强制使用short或Short的限制，请使用这些类型。当您知道应该只有大约小于32,000的值并且希望编译器或运行时JVM强制使用该值时，请选择这些值。
例如，将101加一：
short oneOhOnePlusOne = ( (short) 101 + (short) 1 ) ;
System.out.println( "oneOhOnePlusOne: " + oneOhOnePlusOne ) ;
102
下一步，尝试超出限制以查看编译器强制执行该限制。
short shortMaxPlusOne = ( Short.MAX_VALUE + (short) 1 ) ;
System.out.println( "shortMaxPlusOne: " + shortMaxPlusOne ) ;
错误：不兼容的类型：可能会从int转换为short
请参阅此code run live at IdeOne.com。
这些各种数字类型可能已放入Java中，以使移植C代码变得更容易，无论是在实践上还是在心理上都更加容易。 Java的发明者深知，在那个时代，大多数尝试使用新编程语言的尝试都因批评“它不像C”而失败。因此，Objective-C（Java的灵感），也因此是C++的怪癖。
因此，实际上，如果您正在移植C代码，请使用匹配类型来复制行为。
顺便说一句……从技术上讲，C实际上不是 定义其数字类型的大小。实际上，实际上，每种C实现都使用Java中看到的大小。
仅供参考，即使是最现代的语言，例如Swift和Kotlin也具有用于8、16、32和64位整数的内置数字类型。
如果您的应用有可能在不基于x86-64的其他硬件上运行，那么您可能要使用这些类型。针对此类硬件的Java替代实现可能会针对较小的类型进行更好的优化。
最好使用基元数组来保存分配的内存
首先，不要强调这一点。不要陷入premature optimization的陷阱。在具有大多数常用应用程序的常规硬件上，使用原语，对象，数组和集合所节省的内存将微不足道。使用适合您的编码上下文的类型（原始/对象）和结构（数组/集合）。
我的做法：
Integer，而不是int）。我有两个原因。首先，我属于希望Java是纯OOP而没有任何原语的Object迷。 （实际上，正在进行研究，以查看基元是否可以在遥远的Java版本中实际上消失。）其次，我发现当我使用基元时，最终需要在需要上下文的对象（例如集合）中使用它。