当我阅读《深入Scala》一书时，提到HotSpot编译器有几个重要的特性，其中之一是“动态去优化”：
这是一种确定优化是否没有的能力，事实上，提高性能并撤消该优化，允许应用其他优化
HotSpot 似乎会尝试各种“优化”，并从中选出最好的。
但我不太明白。这里的“优化”都是HotSpot提供的吗？我的意思是程序员经常尝试用一些技巧来优化代码，HotSpot 会处理它们吗？
HotSpot 会尝试任何常见的“优化”吗？
【问题讨论】：
标签： java optimization jvm-hotspot
Oracle 提供了(rather concise) summary of this performance techniques applied by the JVM。它解释了：
去优化是将优化的堆栈帧更改为 一个未优化的。对于编译方法，它也是 丢弃具有无效乐观优化的代码的过程， 并将其替换为优化程度较低、更健壮的代码。一种方法可能在 原则被反优化数十次。
在这个总结中，去优化的原因列举如下：
- 编译器可能会存根一个未使用的分支并在它被使用时取消优化。
- 同样适用于历史上从未失败的低级别安全检查。
- 如果调用站点或转换遇到意外类型，编译器会取消优化。
- 如果加载的类使早期的类层次结构分析无效，则任何线程中的任何受影响的方法激活都将被强制执行 到安全点并取消优化。
- 这种间接去优化是由依赖系统调节的。如果编译器做出未经检查的假设，它必须注册一个 可检查的依赖关系。 （例如，类 Foo 没有子类，或者 Foo.bar 方法没有覆盖。）
就个人而言，我在微基准测试中发现this blog entry 非常易读，其中还涵盖了 HotSpot VM 上的优化和反优化主题。另外，我可以推荐reading through this presentation。
【讨论】：
HotSpot 的优化不同于开发人员在 Java 源代码级别所做的优化，尽管其中一些具有相同的净效果。
这是 JIT 编译器库的一部分：
最有趣的部分是一些优化之间的协同作用，例如：
但是，据我所知，您的报价是错误的。优化后的代码不会进行任何自我分析，因为它会减慢速度。去优化的唯一条件是违反了代码是 JIT 编译的乐观假设。示例：给定的方法调用站点仅接收一种类型的对象，专门用于该对象（编译为单态调用站点），但随后出现了不同的对象类型。现在优化后的代码无法执行，必须取消优化。
【讨论】：
“编译器优化”是一种代码转换，试图在某种意义上使其变得更好——通常，它需要更少的时间来执行。 Wikipedia article on optimizing compilers 有一个很好的常用优化列表； Hotspot JIT 编译器可能会完成所有这些工作，甚至更多。
所以这本书的意思是，Hotspot 会将其中一些技术应用到代码中，看看它是否提高了运行时，如果没有，它将恢复它。
正如您所说的那样，手动更改代码以使其更好的过程也称为“优化”或“手动优化”。编译器尝试应用尽可能多的优化，但仍然需要手动应用许多可能的修改。再次，Wikipedia has a solid article about what a program optimization is。
【讨论】：