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