Java 关于热点的动态反优化

当我阅读《Scala深入》一书时，它提到HotSpot编译器有几个重要特性，其中之一是“动态去优化”：

这是一种确定某个优化实际上是否没有提高性能并撤销该优化，从而允许应用其他优化的能力

热点似乎会尝试各种“优化”，并从中选择最好的一种

但我不太明白。这里的“优化”都是由HotSpot提供的吗？我的意思是程序员经常尝试用一些技巧来优化代码，HotSpot会处理它们吗

“编译器优化”是对代码的一种转换，目的是在某种意义上使代码变得更好——通常，它需要更少的时间来执行。有一个很好的列表，列出了常用的优化方法；Hotspot JIT编译器可能会执行所有这些操作，甚至更多操作

所以这本书的意思是Hotspot将把这些技术中的一些应用到代码中，看看它是否改善了运行时，如果没有，它将恢复运行时

---

正如您正确指出的，手动更改代码以使其更好的过程也称为“优化”或“手动优化”。编译器尝试应用尽可能多的优化，但许多可能的修改仍然需要手动应用。同样，.

HotSpot的优化与开发人员在Java源代码级别所做的优化是不同的，尽管有些优化具有相同的净效果

这是JIT编译器库的一部分：

• 方法调用内联
• 从循环中提升值
• 单态呼叫位点
• 在堆栈上放置对象，以逸出分析为准
• 将变量绑定到CPU寄存器
• 锁省略

最有趣的部分是一些优化之间的协同作用，例如：

呼叫站点实现为单态

这允许方法内联

它邀请对象的堆栈放置

它允许对象的字段绑定到寄存器

然而，据我所知，你的报价是错误的。优化后的代码不会进行任何自评测，因为这样会降低速度。非优化的唯一条件是违反JIT编译代码时的乐观假设。示例：给定的方法调用站点只接收一种类型的对象，对该对象进行专门化（编译为单态调用站点），但随后会出现不同的对象类型。现在，优化后的代码无法执行，必须进行去优化。

Oracle提供了。它解释说：

去优化是将优化的堆栈帧更改为 未优化的。对于编译方法，它也是 丢弃带有无效乐观优化的代码的过程， 并用优化程度较低、更健壮的代码取代它。一种方法可能是 这一原则可能会被多次去优化

在本总结中，取消优化的原因如下：

编译器可能会删除一个未清除的分支，并在执行时对其进行去优化

同样，对于历史上从未失败过的低级安全检查

如果调用站点或强制转换遇到意外的类型，编译器将取消优化

如果加载的类使早期的类层次结构分析无效，则会强制任何线程中受影响的方法激活 到一个安全点，并去优化

这种间接的去优化是通过依赖系统来实现的。如果编译器做出未经检查的假设，则必须注册 可检查的依赖关系。（例如，该类Foo没有子类，或 方法Foo.bar没有替代。）

就我个人而言，我发现微观基准测试非常可读，其中还涵盖了HotSpot VM上的优化和去优化主题。还有，我可以推荐