据我的一些客户反馈，在Windows 7上以Windows XP兼容模式运行Java应用程序可以使其运行更快，但是为什么呢？
我自己似乎没有这个问题，但他们发现该应用程序似乎在闲置状态下占用了100%的CPU，将exe文件或调用Java的批处理文件的属性设置为Windows XP兼容模式即可解决，这是怎么回事呢？
在Windows XP兼容模式下运行的Java应用程序在Windows 7上运行速度更快
10
- Paul Taylor
6
我不是说我知道为什么，但你有检查它是32位JVM还是64位JVM吗？ - Edwin Buck
1感谢您的客户找到了适合他们的解决方案。您的Java应用程序是32位还是64位？您的客户的Windows 7机器是32位还是64位？ - Gilbert Le Blanc
是的，我认为Windows7是64位的，应用程序可以是32位或64位的。坦白地说，由于我自己无法复制这个问题，我很难追踪到它的原因，但我想知道是否有人能够理解为什么在兼容模式下运行应用程序会更好。 - Paul Taylor
也许包装器是主要的罪魁祸首（使用Windows XP功能），顺便问一下，你使用什么包装器？ - Rafael
@Rafael，jsmooth但是有一个客户报告说仅使用批处理文件和纯Java出现问题。 - Paul Taylor
JSmooth只支持32位，而且非常过时（最后一次发布是在2007年），所以可能使用旧的Windows XP调用。关于你的用户仅使用批处理文件，他可能正在使用过时的JVM版本（例如1.5或类似版本）。 - Rafael
3个回答
4
没有确定的答案，只有一个诊断实际发生情况的方法。
您需要确认哪个进程正在消耗CPU以及它的确切操作方式，例如通过监视系统调用：像Sysinternals工具（例如Process Explorer和Process Monitor）可以提供关于问题可能出在哪里的线索。至少，您可以将执行配置文件与XP兼容模式下的执行配置文件进行比较。
由于问题可能来自Java应用程序本身，您应该尝试使用Netbeans Profiler等工具对JVM进行剖析。也许代码依赖于一些旧的Windows XP特定内容，例如目录结构或环境变量，在Windows 7中已不再存在或已更改（但您保留/重新应用到自己的安装中）...导致错误处理不当并无限重试的循环。
本机Windows分析器也是一种选择，但如果涉及Java代码，则因为JIT而过于难以分析，而且没有JVM源代码。
您需要确认哪个进程正在消耗CPU以及它的确切操作方式，例如通过监视系统调用：像Sysinternals工具（例如Process Explorer和Process Monitor）可以提供关于问题可能出在哪里的线索。至少，您可以将执行配置文件与XP兼容模式下的执行配置文件进行比较。
由于问题可能来自Java应用程序本身，您应该尝试使用Netbeans Profiler等工具对JVM进行剖析。也许代码依赖于一些旧的Windows XP特定内容，例如目录结构或环境变量，在Windows 7中已不再存在或已更改（但您保留/重新应用到自己的安装中）...导致错误处理不当并无限重试的循环。
本机Windows分析器也是一种选择，但如果涉及Java代码，则因为JIT而过于难以分析，而且没有JVM源代码。
- Yves Martin
0
没有直接的解决方案，但你的问题相当开放。
如果你的客户能够稳定地重现这个问题，你可以看看是否愿意发送远程协助请求，让你进入他们的桌面。然后至少你可以看到问题的发生，并尝试使用其他人提到的工具在他们的机器上进行调试。
- BitwiseMan
-1
这是由于内部任务切换。与 Windows 7 相比，Windows XP 兼容模式下的任务切换更多。这可能也是防火墙引起的。请检查您在 Windows 7 中的防火墙状态。
- Rushi
2
2你的意思是什么？切换哪些任务，内部切换到什么？“相比Windows 7，切换……更多”。更多什么？你能提供一些来源吗？ - ymajoros
我认为他在暗示XP模式下的内部任务切换比原始的Windows 7更具性能。 - Miere
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接