我们正在开发一个由Java编写的swing应用程序，它只需要大约128MB的内存，并且在短期内我不会看到它需要更多的内存，如4GB。以前我们总是提供3个不同的版本，一个用于32位Windows，一个用于32位Linux，另一个用于64位Linux，安装程序包含JRE。几周之前，任何人都没有使用64位版本，并且报告了OutOfMemoryException，因为该应用程序比32位版本消耗大约40-50％的内存。
我的问题是，如果应用程序永远不需要使用超过4GB的内存，我们是否需要为64位Linux提供64位版本？我们进行了一些快速测试，结果显示32位版本也适用于64位Linux。但我不确定我们可能会有什么缺点，例如：性能和/或兼容性问题？
检查这个64 bit java
如果您的应用程序没有为64位主机操作系统提供任何改进，并且与32位版本兼容，那么我认为不需要立即提供它。
但是，大多数（如果不是全部）新系统都基于x64架构，我提倡64位软件也应该是自然默认的。您越接近硬件级别，这种需求就会越来越强烈。我不能告诉你运行虚拟操作只是为了支持某些32位VPN客户端是多么的糟糕。
如果您决定将其作为首选选项，则升级64位客户端可能会影响您的下载统计信息。
大多数32位JVM限制在1.2-1.5 GB左右。
如果您发现应用程序在64位JVM中使用了更多内存，请尝试使用-XX:+UseCompressedOops，它告诉64位JVM使用32位引用但仍可以访问32 GB内存。
我的问题是，如果应用程序永远不需要使用超过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'd版本的Java上试图支持产品。
根据this Q&A的说法，Azul可以提供32位Java 11。 （我注意到Linux的Java 11的32位“Zulu”版本，但不适用于Windows或MacOS.YMMV。）