Java JDK 32 位与 64 位
我正在创建一个非常简单的应用程序,它读取和显示文本文件并搜索它们。
我问自己是否有兴趣向用户推荐 32 位和 64 位版本。
64 位版本的区别仅在于可以访问更多内存堆大小还是还有其他兴趣?
32 位编译后的程序能否在 64 位 JVM 上运行(我假设是)
I am creating a quite simple application which reads and display text files and search through them.
I am asking myself if there is any interest for me to propose 32 and 64 bits version to the user.
Is the difference only in having access to more memory heap size with the 64 bit version or is there any other interest ?
Will a 32 bit compiled program work on a 64 bits JVM (I assume yes)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
任何程序的 32 位和 64 位版本之间的唯一区别是机器字的大小、可寻址内存量以及所使用的操作系统 ABI。对于 Java,语言规范意味着机器字大小和操作系统 ABI 的差异根本不重要,除非您也使用本机代码。 (本机代码必须构建为与将加载它的 JVM 的字大小相同;如果没有非常奇特的情况,您不能在同一进程中混合 32 位和 64 位构建确实是编码,但你不应该用 Java 来这样做。)
The only differences between 32-bit and 64-bit builds of any program are the sizes of machine words, the amount of addressable memory, and the Operating System ABI in use. With Java, the language specification means that the differences in machine word size and OS ABI should not matter at all unless you're using native code as well. (Native code must be built to be the same as the word-size of the JVM that will load it; you can't mix 32-bit and 64-bit builds in the same process without very exotic coding indeed, and you shouldn't be doing that with Java about.)
唯一对我来说改变它的时候是当涉及到本地库以某种方式推动它时。如果您只是在 Java 领域,那么实际上,除非您需要 > 4GB 的堆大小,否则差别很小。
编辑:差异包括它使用的内存比 32 位稍多,如果您使用 6u23 之前的版本并且不使用
-XX:+UseCompressedOops
,则显着更多。两者之间可能也存在轻微的性能差异,但同样没有什么大的差异。The only times that have swung it for me is when there have been native libraries involved that have pushed it one way or the other. If you're just in Java land then realistically, unless you need >4GB of heap size, there's very little difference.
EDIT: The differences include things like it uses slightly more memory than 32 bit, significantly more if you're using a version before 6u23 and aren't using
-XX:+UseCompressedOops
. There may also be a slight performance difference between the two, but again nothing huge.