64 位 JVM 中是否存在任何错误或不兼容问题？
我和一个朋友正在用 Java 编写一个小游戏。 它的编码有点糟糕，我们正在努力重构它，但这并不是现在的真正问题。 我们都有 64 位机器，我猜之前我们都使用 32 位 JDK，但最近我遇到了一些问题，所以我删除了所有 JDK 并安装了最新的 64 位 JDK，我不确定什么时候，但我的朋友也是现在运行 64 位 JDK。 我们的游戏在 32 位 JDK 中运行良好，但在 64 位版本中游戏无法启动。 我一直在尝试用eclipse来调试它，但是有点痛苦。
我们的游戏是网络化和多线程的，我认为我们在如何同步事物方面存在一些问题（当我之前编写它时，我没有完全理解同步的整个概念），例如。 我们已经使 run() 方法同步，但这没有任何效果，但尽管我们的大部分代码都很愚蠢，但这些东西仍然在 32 位 JVM（Windows 和 Linux）上运行。
游戏从一个人主持游戏开始，然后其他人可以加入，直到主持人决定开始游戏。 然后它会向所有玩家发送提示，询问他们是否要开始，如果所有人都说是，则游戏开始。 64 位 JVM 上发生的情况是，它发送了消息，但似乎响应丢失了或者发生了其他情况，或者服务器没有正确计算每个人都已确定，因为游戏实际上并未开始。 实际上，主机收到了其他玩家没有收到的更多消息，并且在开始游戏方面取得了一些进展，但服务器似乎卡在了某个地方。
任何想法可能是什么问题？ 如果有人想看的话，我们的代码位于 github 上。 如果您这样做，我会非常高兴，但我不希望有人费力地浏览我们丑陋的代码。 谢谢！
顺便说一句，我们都在 64 位 Windows Vista 和 JDK 1.6 u12 和 u14 上运行，但我们也运行 Linux，尽管我还无法在 64 位 Linux JVM 上测试它。 哦，关于为什么我很确定这是一个 64 位 JVM 问题的更多细节：
所以我们基本上在秋季学期就在研究这个问题，并停止了一段时间。 6 个月后，我们再次拿起它，对我们可怕的代码感到震惊，并开始尝试清理它。 然后我们意识到我们都无法正确运行它。 我试图找到一个有效的修订版，但我在今年夏天开始研究之前找到了最后一个修订版，但它仍然不起作用。 然后我什至检查了一些我之前编译过的二进制文件 (.jar)，甚至我拥有的最早的版本也无法在 64 位 JVM 上运行。 然后我检查了一个运行 Sun JDK1.6 JVM 的 32 位 Linux VM，它工作得很好。 因此，我很确定这是一个 64 位问题，因为在相同的二进制文件可以完美运行之前。
我还注意到，当连接到我自己的计算机上的服务器时（0:0:0:0:0:1 而不是 127.0.0.1），Vista 出于某种原因将 IPv6 地址分配给我的套接字，但我修复了所有问题是 IPv4 特定的，但它仍然无法工作。
实际上，我刚刚在我的 github 存储库上创建了另一个问题，这是一个完全不同的悲惨故事，所以我现在无法在另一台机器上测试我的最新版本。 但重构前的最后一个构建在具有双核的 32 位 JVM 上运行良好，因此它看起来不像竞争条件。
哦，另一件事，在 Linux 下的 OpenJDK 6 64 位下运行完全相同的问题。 我猜这是 64 位版本以某种方式带来的竞争条件。
I've got a little game that a friend and I are writing in Java. It's kind of badly coded and we're working on refactoring it, but that's not really the issue right now. We both have 64 bit machines and I guess before we were both using 32 bit JDKs, but recently I had some problems and so I removed all JDKs and installed the latest 64 bit JDK, and I'm not sure when but my friend is also now running a 64 bit JDK. Our game was running fine in the 32 bit JDK, but with the 64 bit version the game won't start. I've been trying to debug it with eclipse, but it's been a bit of a pain.
Our game is networked and multithreaded, and I think we have some issues with how we synchronized things (I didn't fully understand the whole idea of synchronization when I was writing it before) eg. we had made our run() methods synchronized which has no effect, but despite the stupidities of large parts of our code the stuff still runs on a 32 bit JVM (Windows and Linux).
The game starts up where one person hosts a game, and then others can join until the host decides to start the game. It then sends a prompt to all the players, asking if they want to start, and if all say yes the game starts. What is happening on the 64 bit JVM is that it sends the message, but it seems like the response is getting lost or something, or the server isn't counting correctly that everyone has OKed because the game doesn't actually start. Actually, the host gets a few more messages that the other player(s) don't get and gets a little farther in starting the game, but the server seems to get stuck somewhere.
Any ideas what might be the problem? Our code is up on github if anyone wants to take a look. I'd be extremely happy if you did, but I don't expect anyone to wade through our ugly code. Thanks!
By the way, we are both running on 64 bit Windows Vista and JDK 1.6 u12 and u14, but we also run Linux although I haven't been able to test it on a 64 bit Linux JVM yet.
Oh, more details about why I'm pretty sure it's a 64 bit JVM isssue:
So we were working on this basically in the fall semester, and stopped working on it for a while. After 6 months we pick it up again, stagger at our horrid code, and start trying to clean it up. Then we realize that neither of us can run it properly. I try to find a revision that works, but I get to the last revision from before we started working on it this summer and it's still not working. I then even checked some binaries (.jars) that I had compiled before and even the earliest revision I have doesn't work on the 64 bit JVM. I then checked in a 32 bit Linux VM running the Sun JDK1.6 JVM, and it worked fine. Thus, I'm pretty sure it's a 64 bit problem since before the same binaries were working perfectly.
I've also noticed that Vista was assigning IPv6 addresses to my sockets for some reason, when connecting to a server on my own machine (0:0:0:0:0:1 instead of 127.0.0.1) but I fixed anything that was IPv4 specific and it's still not working.
I actually have just created another problem on my github repository which is a whole other tale of woe, so I can't test my latest build on another machine right now. But the last build before refactoring works fine on a 32 bit JVM with a dual core, so it doesn't look like a race condition.
Oh, another thing, exact same problem running under OpenJDK 6 64 bit under Linux. I'm guessing it's a race condition that the 64 bit version somehow brings out.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这听起来可能是竞争条件，即同步有缺陷或丢失。 由于竞争条件与时间相关，因此几乎任何事情（包括切换 JVM）都可能导致它们出现。
我不再担心 64 位与 32 位，而是尝试诊断实际问题。 由于它涉及多台机器，因此不幸的是它会非常困难（通常是竞争条件的情况）。
最好的方法可能是确保所有计算机都使用 NTP 同步时钟，然后使用毫秒时间戳记录消息的发送、接收和处理，以便您可以看到消息丢失或未正确处理的位置。
This sounds like it might be a race condition, i.e. flawed or missing synchronization. Since race conditions are timing-dependant, almost anything (including switching JVMs) can cause them to manifest.
I'd stop worrying about 64bit vs 32bit and try to diagnose the actual problem. Since it involves multiple machines, it's unfortunately going to be very hard (which is generally the case with race conditions).
The best way to do it is probably to make sure all machines have synchronized clocks using NTP, and then log the sending, receiving and processing of messages with millisecond timestamps so you can see where messages get lost or aren't processed properly.
我们发现了问题所在。 在一个部分中有一个循环，其中一个线程等待另一个线程正在处理的某些内容准备就绪，但它只是一个 while(!ready){} 循环。 看起来在 64 位 JVM 线程中不会被抢占或其他什么，因为在 32 位 JVM 中这个循环会被抢占，然后另一个线程会完成并将变量设置为 true，但在 64 位 JVM 中不会。 我现在明白，我们应该使用等待/通知和锁来做到这一点，但至少暂时抛出一个 sleep() 在那里修复它。 不完全是一个竞争条件，看起来更像是线程模型的一个怪癖，所以我不接受任何其他答案，因为他们没有回答我提出的问题。
We found out what the issue was. There was a loop in one part where a thread waited on something to become ready that another thread was working on, except it was just a while(!ready){} loop. It seems like in the 64 bit JVM threads don't get preempted or something, because in the 32 bit JVM this loop would get preempted and then the other thread would finish and set the variable to true, but not in the 64 bit JVM. I understand now that we should have used wait/notify and locks to do this, but at least temporarily throwing a sleep() in there fixed it. Not exactly a race condition, more of a quirk of the threading model it seems, so I'm not accepting any of the other answers since they didn't answer the question I asked.
您是否使用 -d64 选项运行 java 进程？ 如果没有，那么我很确定您仍在以 32 位模式运行 JVM，并且您的问题可能与环境或操作系统有关，而不是与位数有关。
Are you running with the java process with the -d64 option? If not, then I'm pretty sure you're still running the JVM in 32-bit mode, and your issue may be related to the environment or the OS instead of the bitness.
在这种情况下，我不认为 64 与 32 会导致任何问题，线程更有可能成为您
使用原始套接字的原因，但要获得正确的结果非常棘手。 考虑为您的网络堆栈使用一个库，例如 Apache Mina，除非该项目的目标是编写自己的套接字代码。 请务必阅读快速入门指南。 它基于文本的协议直接映射到您正在使用的内容。
旁注：在每个方法上坚持同步并使用 Finalize 是不好的事情/代码气味的症状
I would not expect 64 vs. 32 to cause any issues in this case, threading is way more likely to be your cause
kudos for using raw sockets, but they're very tricky to get correct. Consider using a library for your network stack, like Apache Mina, unless of course the goal of the project is to write your own socket code. Definitely read over the quick start guide. It's text-based protocol maps directly to what you're using.
Side note: sticking synchronized on every method and using finalize are symptoms of bad things / code smells