不同操作系统的 Java 程序效率 [关闭]答案

【问题标题】：Java program efficiency with different OSs [closed]不同操作系统的 Java 程序效率 [关闭]
【发布时间】：2023-03-23 02:26:02
【问题描述】：

我最近遇到了一个与 Java 相关的问题（意译）：

Java 应用程序可能在操作系统 A 上以合理的速度运行，但在操作系统 B 上运行缓慢的原因是什么？
程序员可以做些什么来纠正这个问题？

我的回答是（我知道我错了，但我会解释我的思考过程）

(1) 应用程序应该在任何带有 JVM 的操作系统上以大致相同的速度运行，因为该应用程序是在虚拟机内部运行的。只要虚拟机设计正确，就没有关系。

(2)呃……

我的问题是：这个问题的正确答案是什么？

【问题讨论】：

您对 (1) 的看法是正确的。但是特定的虚拟机可能在应用程序使用的特定操作系统上对特定功能的实现存在错误。尝试更改 JVM 实现。只要您运行的是符合 Java 规范的 JVM，您的应用程序就应该被忽略。另外 - 通过分析器运行它。

标签： java operating-system jvm

【解决方案1】：

这是一个“一段字符串有多长”的问题 - 也就是说，OS B 的行为与 OS A 不同的原因有很多。

您对 (1) 的看法也不正确。

例如，在我教授的性能调优课程中，我有一个示例，其中一个相对简单的示例（相当容易理解和推理）在 Linux 上以大约 1.0 的速度运行，在 Mac 上以 1.2 的速度运行，在 Mac 上以 2.1 的速度运行Windows 和 1.5 for Linux 在 Mac 上虚拟化。

也有病理病例。例如，有（或曾经有）乐高头脑风暴的 JVM 实现。它们不执行 GC，因此您基本上可以构建行为任意不良的示例。

您甚至不必去不同的操作系统就可以看到奇怪的性能效果。我见过一些例子，其中 UAT 系统与生产系统相同，只是 PROD 的核心和 SSD 数量是 HDD 的两倍。

团队推断，PROD 中的性能会更好（或者，最坏的情况，不低于）UAT 中的性能。毕竟，PROD 中的套件更好，所以不会出错，对吧？

PROD 中的性能实际上更差。额外的内核和 SSD 导致应用程序以 I/O 为主，因为 SSD 比 HDD 快。这导致吞吐量崩溃。

诊断操作系统之间的性能差异应该使用的一般方法相对简单：

不要以为你知道问题出在哪里。将此视为您要解决的“未知未知”问题。
听听系统告诉你什么。阅读它的基本生命统计数据 - 内存消耗、分页活动、内存页面错误、线程可运行队列的大小、JVM GC 活动（并确保为您的进程打开了所有正确的开关）
默认情况下不要使用分析器或任何其他工具。首先阅读并分析系统统计信息。如果您的系统与 I/O 挂钩，除非您真的知道自己在做什么，否则分析器可能会在某些操作系统上为您提供完全错误的结果。
一旦您认为您已经确定了问题（是 I/O、CPU 不足、GC、程序代码还是其他问题），请尝试测试您的理论。
如果您是对的，那么请使用细粒度的专用工具（例如用于 GC 的 GC 日志分析器，或者如果您怀疑它是应用程序代码，则使用分析器）。

这应该可以让您相当快地找到问题所在。

【讨论】：

【解决方案2】：

一切都与实施有关。

问题在于 JVM 本身是一个在主机操作系统上本地运行的程序，负责实现符合语言和库规范的 Java 库。此实现需要管理系统资源（例如文件、线程、套接字等），并且每个操作系统可能都有自己关于管理这些资源的“最佳实践”，这可能不一定与各种 Java 规范的设计保持一致.此外，操作系统本身实现了这些系统资源的接口，其实现可能不如其他操作系统那么健壮。

例如，几年前，Linux 线程实现的性能远低于类似 UNIX 操作系统（例如 Solaris、AIX 等）上的相同 POSIX 线程 API。因此，在 Linux 机器上运行的 JVM 与在 Solaris 机器上运行的 JVM 具有相同的功能，但 Linux JVM 会受到该操作系统上（当时）不太出色的线程实现的阻碍。

【讨论】：

+1 线程示例也是我想到的（我在考虑 Windows 中的 CriticalSection 与 linux 中的相应锁）。除了不使用这些功能外，我们无能为力来纠正这些问题，但这几乎不是“解决方案”。
不直接相关，但出于同样的原因，性能也可能因您的硬件而异。例如，许多 java.util.concurrent 类的性能依赖于 compareAndSet。在没有 CAS 的 CPU 上，这必须转换为同步块。