在 64 位 VM 中，使用 long 而不是 int 在性能方面会更好，因为 long 在 java 中是 64 位，因此在 64 位系统中拉取和处理 64 位字可能比拉取 32 位字更快。（我期待很多NO，但我正在寻找一个详细的解释）。
编辑：我是在暗示“在64位系统中拉取和处理64位单词可能比拉取32位单词更快”，因为我假设在64位系统中，拉取32位数据将要求您首先获取64位单词，然后掩盖前32位。
使用 for 可能会减慢您的速度。longint
您最关心的问题是，在 64 位 CPU 上是否需要额外的处理时间。这在现代流水线 CPU 上极不可能。我们可以通过一个小程序轻松测试这一点。它所操作的数据应该足够小以适合L1缓存，以便我们正在测试这个特定的关注点。在我的机器（64位英特尔酷睿2四核）上，基本上没有区别。int
在实际应用中，大多数数据不能驻留在 CPU 缓存中。我们必须担心将数据从主内存加载到缓存，这相对非常慢，通常是瓶颈。这种加载在“缓存行”的单位上工作，该单位为64字节或更多，因此加载单个或将花费相同的时间。longint
但是，使用会浪费宝贵的缓存空间，因此缓存未命中会增加，这是非常昂贵的。Java的堆空间也受到压力，因此GC活动将会增加。long
我们可以通过读取具有相同数量元素的巨型数组来证明这一点。它们比缓存可以包含的要大得多。长版本在我的机器上花费的时间增加了65%。该测试受内存>缓存的吞吐量的约束，并且 long[] 内存量大 100%。（为什么不多花100%的时间超出了我的范围;显然其他因素也在起作用）long[]int[]
我总是根据您的问题域使用正确的数据类型。
我的意思是，如果你需要64位长，那么使用64位长，但如果你不需要64位长，那就使用int。
在 64 位平台上使用 32 位并不昂贵，并且基于性能进行比较是没有意义的。
对我来说，这看起来不对：
for(long l = 0; l<100; l++)
//SendToTheMoon(l);
并且与它无关。SendToTheMoon
