将使用long而不是int在64位Java中受益

在64位VM中，考虑到long在Java中是64位，因此使用而不是

在性能方面会做得更好，因此在64位系统中提取和处理64位字可能比提取32位字更快。（我期望有很多NO，但我正在寻找详细的解释）。

：我是说“在64位系统中，拉和处理64位字可能比拉32位字要快”，因为我假设在64位系统中，拉32位数据将需要您首先获得64位。位字，然后屏蔽前32位。

一般而言，使用longfor int可能会使您减速。

您直接关心的是int在64位CPU上是否需要额外的处理时间。在现代流水线CPU上，这种情况极不可能发生。我们可以使用一个小程序轻松地对此进行测试。它所处理的数据应足够小以适合L1缓存，以便我们测试此特定问题。在我的机器（64位Intel

Core2 Quad）上，基本上没有区别。

在实际应用中，大多数数据不能驻留在CPU缓存中。我们必须担心将数据从主内存加载到缓存中，这是一个非常缓慢的过程，通常是一个瓶颈。这样的加载以“缓存行”为单位，该行为64字节或更多，因此加载单个long或int将花费相同的时间。

但是，使用long将浪费宝贵的缓存空间，因此缓存未命中将增加，这非常昂贵。Java的堆空间也很紧，因此GC活动将增加。

我们可以通过阅读大量证明这一点long[]和int[]阵列与相同数量的元素。它们比缓存所能容纳的更大。较长的版本在我的计算机上花费的时间增加了65％。该测试受memory->

cache的吞吐量限制，并且long []内存量大100％。（为什么不花100％的时间超出我；显然其他因素也在起作用）