为什么不是'；有更多的Java软件是本机编译的吗？

我意识到字节码与本机代码的区别（可移植性）

但是如果您总是知道您的代码将在x86体系结构上运行，那么为什么不为x86编译并获得性能优势呢

---

请注意，我假设本机代码编译有一个性能增益。一些人回答说，实际上可能没有任何收益，这对我来说是新闻。

字节码在Java虚拟机中运行，该虚拟机是为（例如）Solaris编译的。对于该操作系统，它将像heck一样进行优化

在现实世界中，您经常会看到Java代码在运行时具有相同或更好的性能，这得益于在虚拟机代码的基础上构建内存管理之类的东西——这些代码多年来一直在发展和成熟

---

为JVM构建的好处不仅仅是可移植性——例如，每次发布一个新的JVM时，您编译的字节码都会得到来自业界最好的优化、算法改进等。另一方面，一旦编译了C代码，就到此为止。

因为使用即时编译，性能优势微不足道

---

实际上，很多事情JIT实际上可以做得更快。

它已经被JIT编译成Solaris本机代码，在运行之后。如果在目标站点上传之前编译它，您将无法获得任何其他好处。

，因为性能增益（如果有的话）不值得费心

此外，垃圾收集对性能非常重要。JVM的GC很可能比嵌入在编译的可执行文件中的GC更好，比如说

而即时编译甚至可以产生更好的性能，因为JIT在运行时比编译器在编译时有更多的信息可用于优化编译。请参阅上的wikipedia页面。

“Solaris”是一个操作系统，而不是CPU体系结构。安装在实际机器上的JVM将编译为本机CPU指令。Solaris可以是SPARC、x86或x86-64体系结构

---

此外，JIT编译器可以根据实际的CPU系列进行特定于处理器的优化。例如，不同的指令序列在Intel CPU上比在AMD CPU上更快，适合您特定平台的JIT编译器可以利用这些信息生成高度优化的代码。

您可能会，也可能不会获得性能优势。但更可能的情况是，您会受到性能损失：静态编译不可能实现JIT优化，因此性能只有在编译器“蒙住眼睛”的情况下才能达到最佳状态（而不需要实际分析程序并相应地对其进行优化，这正是HotSpot之类的JIT编译器所做的）

---

从直觉上看，编译的成本（资源方面）是如此之低，而且通过观察正在运行的程序可以自动优化多少，这是相当令人惊讶的。黑魔法，但对我们有好处：-）

所有关于JIT的讨论都已经过时七年了。顺便说一句，现在有关的技术被称为热点，它不仅仅是JIT。

我想是因为JIT（即时）编译非常先进。

为什么不为x86编译呢

因为这样你就不能利用运行它的特定cpu的特定特性。特别是，如果我们将“为x86编译”理解为“生成可以在386及其子代上运行的本机代码”，那么生成的代码就不能依赖于甚至像mmx指令这样古老的东西

因此，最终的结果是，您需要为它将运行的每一个确切的体系结构进行编译（那些还不存在的体系结构如何），并让安装程序选择要放置的可执行文件。或者，我听说英特尔C++编译器将产生相同版本的几个版本，只对CPU的特性进行不同的选择，并根据CPU的可用性在运行时选择正确的版本。 另一方面，您可以将字节码视为“半编译”源代码，类似于本机编译器（除非要求）不会实际写入磁盘的中间格式。然后，运行时环境可以进行最终编译，确切地知道将使用什么体系结构。这就是为什么一些C·./NET代码在一些基准测试中可以在某些CPU密集型任务上略微优于C++代码的原因。p>

---

字节码的“最终编译”还可以做出（从静态编译的角度来看）明显不安全的额外优化假设*，如果以后发现这些假设有误，只需重新编译。

我认为这是可能的，我将与您一起等待答案）Solarix x64或SPARC顺便说一句，可移植性不是唯一的好处。最obvious@Jenea，我更新了帖子以指定特定的CPU。指定x86只是一个示例。有点过时（不包括Solaris平台），但仍然很有趣：对，但Solaris JVM将Java字节码指令编译为本机Solaris指令。这需要时间。你真的认为编译时间是一个瓶颈吗？你真的能用你自己编写的本机代码证明性能提升吗？我只是假设至少会有一些性能提升。这是一个假设性的问题-不存在任何特定的用例（在我的例子中）。那么为什么这么多用java编写的桌面应用程序看起来比较慢？UI（Swing）开发很难正确进行，而且大多数程序员都不知道他们在做什么。Swing应用程序可以做出非常灵敏的响应，但大多数程序员不了解Swing线程和事件系统，导致代码效率极低。我不同意。看这里。另外还有一个C++和C++的例子。但即使在这个图表上，托管和非托管的性能差异也高达100%。@Marcus还注意到JIT编译器在运行时优化了代码；经常跟随的c