Java 32 位与 64 位兼容性
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/783662/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java 32-bit vs 64-bit compatibility
提问by mshafrir
Will Java code built and compiled against a 32-bit JDK into 32-bit byte code work in a 64-bit JVM? Or does a 64-bit JVM require 64-bit byte code?
针对 32 位 JDK 构建和编译为 32 位字节代码的 Java 代码是否可以在 64 位 JVM 中运行？还是 64 位 JVM 需要 64 位字节码？
To give a little more detail, I have code that was working in a Solaris environment running a 32-bit JVM, but now I'm getting issues after upgrading the JDK and Weblogic Server to 64-bit.
为了提供更多细节，我的代码在运行 32 位 JVM 的 Solaris 环境中运行，但现在我在将 JDK 和 Weblogic Server 升级到 64 位后遇到问题。
采纳答案by Zifre
Yes, Java bytecode (and source code) is platform independent, assuming you use platform independent libraries. 32 vs. 64 bit shouldn't matter.
是的，Java 字节码（和源代码）是独立于平台的，假设您使用独立于平台的库。32 位与 64 位应该无关紧要。
回答by Tom Hawtin - tackline
Yes to the first question and no to the second question; it's a virtual machine. Your problems are probably related to unspecified changes in library implementation between versions. Although it could be, say, a race condition.
第一个问题是，第二个问题不是；它是一个虚拟机。您的问题可能与版本之间库实现的未指定更改有关。虽然它可能是，比如说，一个竞争条件。
There are some hoops the VM has to go through. Notably references are treated in class files as if they took the same space as ints on the stack. doubleand longtake up two reference slots. For instance fields, there's some rearrangement the VM usually goes through anyway. This is all done (relatively) transparently.
VM 必须经历一些障碍。值得注意的是，类文件中的引用被视为在int堆栈中占用与s相同的空间。double并long占用两个参考槽。例如，虚拟机通常会经历一些重新排列。这一切都是（相对）透明地完成的。
Also some 64-bit JVMs use "compressed oops". Because data is aligned to around every 8 or 16 bytes, three or four bits of the address are useless (although a "mark" bit may be stolen for some algorithms). This allows 32-bit address data (therefore using half as much bandwidth, and therefore faster) to use heap sizes of 35- or 36-bits on a 64-bit platform.
还有一些 64 位 JVM 使用“压缩 oops”。因为数据大约每 8 或 16 个字节对齐，所以地址的三或四位是无用的（尽管某些算法可能会窃取“标记”位）。这允许 32 位地址数据（因此使用一半的带宽，因此速度更快）在 64 位平台上使用 35 位或 36 位的堆大小。
回答by Fortyrunner
I accidentally ran our (largeish) application on a 64bit VM rather than a 32bit VM and didn't notice until some external libraries (called by JNI) started failing.
我不小心在 64 位虚拟机而不是 32 位虚拟机上运行了我们的（大型）应用程序，直到一些外部库（由 JNI 调用）开始失败时才注意到。
Data serialized on a 32bit platform was read in on the 64bit platform with no issues at all.
在 32 位平台上序列化的数据在 64 位平台上读入完全没有问题。
What sort of issues are you getting? Do some things work and not others? Have you tried attaching JConsole etc and have a peak around?
你遇到了什么样的问题？有些事情有效而不是其他的吗？您是否尝试过附加 JConsole 等并达到峰值？
If you have a very big VM you may find that GC issues in 64 bit can affect you.
如果您有一个非常大的 VM，您可能会发现 64 位的 GC 问题会影响您。
回答by Peter Lawrey
All byte code is 8-bit based. (That's why its called BYTE code) All the instructions are a multiple of 8-bits in size. We develop on 32-bit machines and run our servers with 64-bit JVM.
所有字节码都是基于 8 位的。（这就是为什么它被称为 BYTE 代码）所有指令的大小都是 8 位的倍数。我们在 32 位机器上开发并使用 64 位 JVM 运行我们的服务器。
Could you give some detail of the problem you are facing? Then we might have a chance of helping you. Otherwise we would just be guessing what the problem is you are having.
您能否详细说明您所面临的问题？那么我们可能有机会帮助你。否则，我们只会猜测您遇到的问题是什么。
回答by Thorbj?rn Ravn Andersen
Unless you have native code (machine code compiled for a specific arcitechture) your code will run equally well in a 32-bit and 64-bit JVM.
除非您有本机代码（为特定架构编译的机器代码），否则您的代码将在 32 位和 64 位 JVM 中运行得同样好。
Note, however, that due to the larger adresses (32-bit is 4 bytes, 64-bit is 8 bytes) a 64-bit JVM will require more memory than a 32-bit JVM for the same task.
但是请注意，由于地址较大（32 位是 4 字节，64 位是 8 字节），对于相同的任务，64 位 JVM 将需要比 32 位 JVM 更多的内存。
回答by javangelo
Add a paramter as below in you in configuration while creating the exe
创建exe时在配置中添加如下参数
I hope it helps.
我希望它有帮助。
thanks...
谢谢...
/jav
/jav
回答by elayer
yo where wrong! To this theme i wrote an question to oracle. The answer was.
哟哪里错了！对于这个主题，我向 oracle 写了一个问题。答案是。
"If you compile your code on an 32 Bit Machine, your code should only run on an 32 Bit Processor. If you want to run your code on an 64 Bit JVM you have to compile your class Files on an 64 Bit Machine using an 64-Bit JDK."
“如果你在 32 位机器上编译你的代码，你的代码应该只在 32 位处理器上运行。如果你想在 64 位 JVM 上运行你的代码，你必须使用 64 位机器在 64 位机器上编译你的类文件-位 JDK。”
回答by John Thomas
The 32-bit vs 64-bit difference does become more important when you are interfacing with native libraries. 64-bit Java will not be able to interface with a 32-bit non-Java dll (via JNI)
当您与本机库交互时，32 位与 64 位的差异变得更加重要。64 位 Java 将无法与 32 位非 Java dll 接口（通过 JNI）
回答by thecarpy
The Java JNI requires OS libraries of the same "bittiness" as the JVM. If you attempt to build something that depends, for example, on IESHIMS.DLL (lives in %ProgramFiles%\Internet Explorer) you need to take the 32bit version when your JVM is 32bit, the 64bit version when your JVM is 64bit. Likewise for other platforms.
Java JNI 需要与 JVM 具有相同“bittiness”的操作系统库。例如，如果您尝试构建依赖于 IESHIMS.DLL（位于 %ProgramFiles%\Internet Explorer）的东西，当您的 JVM 是 32 位时，您需要使用 32 位版本，当您的 JVM 是 64 位时，您需要使用 64 位版本。其他平台也一样。
Apart from that, you should be all set. The generated Java bytecode s/b the same.
除此之外，你应该一切准备就绪。生成的Java字节码s/b相同。
Note that you should use 64bit Java compiler for larger projects because it can address more memory.
请注意，对于较大的项目，您应该使用 64 位 Java 编译器，因为它可以处理更多内存。
