I am a newbie to Java and I have this app developed by someone else which is having some issues. This Java app works well on windows xp 32 bit, but there is a delay while running on 64 bit windows 2008 R2 server. I have asked the customer to make sure that they are running the 32 bit version of JRE. I have checked the traces for the application and the application has an issue while calling a synchronized block always. This synchronized block adds the data into a queue from which it is picked up by some other process. I have checked the traces if some other process is using the block but it isn’t. The only confusing part is that the same app runs perfectly on windows xp 32 bit.
我是Java的新手，我有这个由别人开发的应用程序，它有一些问题。这个Java应用程序在Windows XP 32位上运行良好，但在64位Windows 2008 R2服务器上运行时有一个延迟。我已要求客户确保他们正在运行32位版本的JRE。我已经检查了应用程序的跟踪，并且应用程序在调用synchronized块时始终存在问题。此同步块将数据添加到队列中，然后由其他进程拾取该队列。如果其他进程正在使用该块，我已经检查了跟踪，但事实并非如此。唯一令人困惑的部分是同一个应用程序在windows xp 32位上运行完美。
After googling I came to know that there are threading issues in win64
谷歌搜索后，我发现win64中存在线程问题
Help me with this.
帮助我。
1 个解决方案
#1
0
This isn't exactly an answer, but it might be of some help and it's more than a comment:
这不是一个答案，但它可能有一些帮助，它不仅仅是一个评论：
Most likely your 64 bit machine has more cores than the 32 machine, making it more likely that two or more threads really will run at the same time and any synchronization problems that never, or rarely, arise on the 32 will quickly pop up on the 64. Also, newer machines tend to execute more instructions at once than older machines. Both types reorder them as they do so. (Also, compilers often reorder the code.) So the 64's are a bit worse to start with, and when you throw in the more extensive, real multithreading the problems multiply.
很可能你的64位机器有比32机器更多的内核，这使得两个或更多线程更有可能同时运行，并且32上从未或很少出现的任何同步问题将很快出现在64.此外，较新的机器往往比旧机器执行更多的指令。这两种类型都会对它们进行重新排序。 （此外，编译器经常对代码进行重新排序。）因此，64开始时会更糟糕，当你投入更广泛，真正的多线程时，问题就会成倍增加。
(This can work the other way: the many-core machines tend to run threads in a predictable order, where a single core machine can wait many minutes to run something you expected would be executed immediately.)
（这可以用另一种方式工作：多核机器倾向于以可预测的顺序运行线程，其中单个核心机器可以等待很多分钟来运行您预期会立即执行的事情。）
I've usually found the best way to fix bugs is to stare at the code and make sure everything is precisely right. (This works better if you know when something is precisely right.) Failing that, you need logging messages that only print out when they're useful (it's hard to sort through a billion of them). You seem to have no trouble reproducing your problems (which almost makes me think it may not be a multithreading problem at all), which should make it a bit easier to figure out.
我经常发现修复bug的最好方法是盯着代码并确保一切都是正确的。 （如果你知道某些东西是完全正确的话，这会更好。）如果不这样做，你需要记录只在它们有用时才打印出来的消息（很难对它们中的十亿个进行排序）。你似乎可以轻松地复制你的问题（这几乎让我觉得它可能根本不是一个多线程问题），这应该让它更容易弄明白。
#1
0
This isn't exactly an answer, but it might be of some help and it's more than a comment:
这不是一个答案，但它可能有一些帮助，它不仅仅是一个评论：
Most likely your 64 bit machine has more cores than the 32 machine, making it more likely that two or more threads really will run at the same time and any synchronization problems that never, or rarely, arise on the 32 will quickly pop up on the 64. Also, newer machines tend to execute more instructions at once than older machines. Both types reorder them as they do so. (Also, compilers often reorder the code.) So the 64's are a bit worse to start with, and when you throw in the more extensive, real multithreading the problems multiply.
很可能你的64位机器有比32机器更多的内核，这使得两个或更多线程更有可能同时运行，并且32上从未或很少出现的任何同步问题将很快出现在64.此外，较新的机器往往比旧机器执行更多的指令。这两种类型都会对它们进行重新排序。 （此外，编译器经常对代码进行重新排序。）因此，64开始时会更糟糕，当你投入更广泛，真正的多线程时，问题就会成倍增加。
(This can work the other way: the many-core machines tend to run threads in a predictable order, where a single core machine can wait many minutes to run something you expected would be executed immediately.)
（这可以用另一种方式工作：多核机器倾向于以可预测的顺序运行线程，其中单个核心机器可以等待很多分钟来运行您预期会立即执行的事情。）
I've usually found the best way to fix bugs is to stare at the code and make sure everything is precisely right. (This works better if you know when something is precisely right.) Failing that, you need logging messages that only print out when they're useful (it's hard to sort through a billion of them). You seem to have no trouble reproducing your problems (which almost makes me think it may not be a multithreading problem at all), which should make it a bit easier to figure out.
我经常发现修复bug的最好方法是盯着代码并确保一切都是正确的。 （如果你知道某些东西是完全正确的话，这会更好。）如果不这样做，你需要记录只在它们有用时才打印出来的消息（很难对它们中的十亿个进行排序）。你似乎可以轻松地复制你的问题（这几乎让我觉得它可能根本不是一个多线程问题），这应该让它更容易弄明白。