5

我们正在开发一个由 Java 编写的 Swing 应用程序，它只需要大约 128MB 内存，而且在不久的将来，我认为它不会需要更多像 4GB 这样的内存。以前，我们始终提供 3 种不同的版本，一种用于 32 位 Windows，一种用于 32 位 Linux，另一种用于 64 位 Linux，并带有包含 JRE 的安装程序。直到几周前，任何人都没有使用 64 位版本，并且报告了 OutOfMemoryException，因为该应用程序消耗的内存比 32 位版本多 40-50%。

我的问题是，如果应用程序永远不需要使用超过 4GB 的内存，我们是否需要为 64 位 Linux 提供 64 位版本？我们进行了一些快速测试，发现 32 位版本也适用于 64 位 Linux。但我不确定我们会有什么缺点，例如性能和/或兼容性问题？

4

4 回答 4

3

如果您的应用程序没有为 64 位主机操作系统提供改进并且与您的 32 位版本兼容，那么我认为没有立即提供它的必要。

但是，大多数（如果不是全部）新系统都基于 x64 架构，我主张 64 位软件也应该是自然默认值。越接近硬件级别，这种需求就越强烈。我无法告诉你仅仅为了支持一些 32 位 VPN 客户端而运行虚拟操作系统是多么尴尬。

如果您决定将其作为首选，那么提升 64 位客户端可能会影响您的下载统计信息。

于 2011-03-03T09:13:31.843 回答
2

检查这个64 位 java

于 2011-03-03T09:21:18.443 回答
2

大多数 32 位 JVM 限制在 1.2-1.5 GB 左右。

如果您发现您的应用程序在 64 位 JVM 上使用了更多内存，请尝试-XX:+UseCompressedOops告诉 64 位 JVM 使用 32 位引用但仍可以访问 32 GB 内存的方法。

于 2011-03-03T09:21:39.723 回答
2

我的问题是，如果应用程序永远不需要使用超过 4GB 的内存，我们是否需要为 64 位 Linux 提供 64 位版本？

如果应用程序不需要那么多内存，64 位安装程序/JVM 不会增加任何价值。相反，这是一个糟糕的选择，因为（正如您所观察到的）它只是使用更多内存并且（可能）因此运行速度较慢。

（实际上，实际限制会小于 4GB。由于硬件架构问题，32 位地址空间的某些部分将无法使用。）

我建议您退出 64 位版本，但为用户提供使用他们单独下载和安装的 JVM 的能力。（实际上，无论如何，您可能应该做后者。当人们升级以获得最新的 JVM 安全修复程序时，JRE 的嵌入式副本往往会被忽视......）

更新 (2019) - Java 8 是 Oracle 为 32 位平台提供的最后一个 Java 版本。从 Java 11（当前的 LTS 版本）开始，适用于 Linux、MacOS、SunOS / SPARC 和 Windows 的带有 Oracle 标志的发行版仅为 64 位。

我现在的建议是尽快将您的产品从 32 位迁移出去。您不想被困在尝试支持 EOL 版本的 Java 上的产品。

当然，根据此问答，Azul 提供了 32 位 Java 11 。（我注意到适用于 Linux 的 Java 11 的 32 位“Zulu”版本，但不适用于 Windows 或 MacOS。YMMV。）

于 2011-03-03T09:56:58.923 回答