最新版本java_java – 最新版本的JVM更快？

性能技术

首先，这取决于你正在谈论哪个JVM，因为有几个 – 但是我要假设你的意思是Oracle HotSpot(在任何情况下，其他的顶级JVM将使用类似的技术)。

对于JVM，HotSpot内部wiki的this list提供了一个很好的开始(并且子页面详细介绍了一些更有趣的技术)。如果你只是在寻找一个洗衣单的技巧，那么维基has that too虽然要理解他们，但你可能需要google个别条款。

并不是所有这些都是最近实施的，但是一些大的(范围检查精灵，逃脱分析，优势优化) – 至少是对“最近”的宽松定义。

接下来，我们来看看C/C++ vs Java的相对性能图片，为什么上面的技术有助于缩小差距，或者在某些情况下实际上给Java和本机编译语言的内在优势。

Java与C/C++

在高层次上，优化是您可以在任何适合于C和C等本地语言的体面编译器中看到的内容，以及减少Java / JVM特定功能和安全检查影响所需的功能，例如如：

>逃避分析，减轻(有点)对象的无栈分配

>内联缓存和类层次分析，减轻“每个功能都是虚拟”

>范围检查消除，这减轻了“每个数组访问范围检查”

许多这些JVM特定的*优化只能帮助JVM达到与母语平等的目的，因为它们解决了母语不必处理的障碍。然而，一些优化是静态编译语言无法管理的东西(或者在某些情况下只能使用轮廓引导的优化来管理，这是罕见的，并且必然是一刀切的)

>动态内联只有最热的代码

>基于实际分支/开关频率的代码生成

>动态生成CPU /指令集感知代码(甚至在编译代码后发布CPU功能！)1

>未执行代码的错误

>注入与应用程序代码交错的预取指令

>整个家庭的技术支持保护

共识似乎是，Java经常在适中的优化级别(如gcc -O2)下生成与优秀C编译器相似的代码，尽管很多取决于准确的基准。像HotSpot这样的现代JVM倾向于在低级数组遍历和数学(只要竞争的编译器没有向量化 – 这是很难击败)，或者当竞争的代码执行相似数量的分配时，重型对象分配的情况下， (JVM对象分配GC通常比malloc快)，但是当典型的Java应用程序的内存损失是一个因素，其中大量使用堆栈分配，或者将编译器或内在函数向量化向本机代码提取时，下降。

如果您搜索Java vs C性能，您会发现很多人已经解决了这个问题，具有不同的严谨程度。这是first one I stumbled across，它似乎在gcc和HotSpot之间显示了一个粗糙的关系(即使在这种情况下也是-O3)。 This post和链接的讨论可能是一个更好的开始，如果你想看到一个单一的基准测试可以通过多次迭代在每种语言，跨越彼此 – 并显示出两方面优化的一些限制。

*真的不是真正的JVM特定的 – 大多数也适用于其他安全或管理的语言，如CLR

1随着新的指令集(特别是SIMD指令，但有others)正在以某种频率发布，这种特殊的优化变得越来越重要。自动向量化可以大大加快一些代码，而Java在这里已经放缓了，至少有catching up。