我正在创建一个相当简单的应用程序，它可以读取和显示文本文件并搜索其中的内容。
我在思考是否有必要为用户提供32位和64位版本。
64位版本只是拥有更大内存堆大小的区别吗？还是有其他方面的优势？
32位编译的程序能否在64位JVM上运行（我认为可以）。
Java JDK 32位和64位有什么区别？
7
- HpTerm
4
4只要您的应用程序是100％纯Java，除了可能的堆大小之外，就没有太大的区别。 - Thomas
请记住，32位和64位的JRE是独立安装的，大多数人默认只安装了32位的（即使在64位机器上）。 - Viruzzo
谢谢你的回答。正如我所预料的，对于纯Java来说，这并不会改变任何事情（除了堆大小）。 - HpTerm
如果您打算将Java程序打包为“应用程序包”（即自包含的.exe/.app/二进制文件，其中包括您的Java和完整的JRE），那么在32位和64位之间进行选择肯定是*必须考虑的。没有人想要安装JRE才能运行您的.jar文件，并且使用32位捆绑的JRE可能比使用64位更能吸引（稍微）更广泛的受众。 - Christopher Schultz
2个回答
12
任何程序的32位和64位版本之间唯一的区别在于机器字大小、可寻址内存量和操作系统ABI使用。对于Java语言来说，语言规范意味着机器字大小和操作系统ABI的差异应该不会有任何影响，除非你也使用本地代码。 （本地代码必须构建为与将加载它的JVM的字大小相同；您不能在同一进程中混合32位和64位版本，除非进行非常奇特的编码，并且不应该使用Java进行此操作。）
- Donal Fellows
14
本地字大小对于C或C++代码可能会产生根本性的影响，尤其是如果编写得很差或使用hack方法时，但Java代码则完全看不到这种差异。 - Donal Fellows
1@HpTerm：在纯Java中，唯一变化的是可寻址内存的数量（好的），以及每个对象的内存量（不太好）。除非您接近VM限制，否则这两个变化都不会导致您能看到的问题。 - Donal Fellows
@Voo：这并不是那么简单。问题不在于lea，而在于计算要加载的地址与lea之间存在数据依赖关系，这会阻碍对访问甚至缓存的流水线处理，因为CPU无法在计算完成之前确定要发出的地址。而且你需要在每次解引用时都付出这样的代价，通常在内部循环中会多次出现。相比之下，一个简单的lea（甚至带有固定偏移量的）更加简单，也更加优化。它通常也是在前一条指令中未创建的值上执行的。 - Donal Fellows
让我们明确一点，花哨的位填充是昂贵的。当涉及地址时，它真的很昂贵，因为它会导致指令流水线出现问题（它迫使CPU的大部分停止并等待计算结果可用）。不是说它必须是这样，而是没有流行的CPU有特定的指令来处理这种情况（如果我没记错的话），也不是CPU设计师优化的一个方案。全宽地址要快得多，因为它们是每个人都优化的情况（因为它在大量代码中使用）。 - Donal Fellows
你似乎对流水线工作方式有一个很大的误解。而且你“真的不认为有人会做那种荒谬的打包”？在声称一些极其可疑的事情之前，也许先阅读一下我们正在讨论的主题会有所帮助？自6.24以来，CompressedOops已经成为任何Hotspot JVM的默认设置，在一般情况下性能损失可以忽略不计。（还要注意，至少在英特尔上，ROB已经重新设计，允许3个依赖项而不是2个，因此也不会受到限制） - Voo
显示剩余9条评论
2
对我来说，唯一让我选择的时候是当涉及到推动它向某个方向的本地库时。如果你只使用Java，则实际上，除非需要> 4GB的堆大小，否则几乎没有什么区别。
编辑：差异包括它比32位使用稍多的内存，在6u23之前的版本中，如果不使用-XX:+UseCompressedOops，则明显更多。两者之间也可能存在轻微的性能差异，但同样不是很大。
- Michael Berry
1
你没有说“没有区别”，而是说“非常小的区别”。只是为了我的了解，假设使用纯Java，这个非常小的区别是什么？ - HpTerm
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接