如何说服 JVM 内联接口方法？

Question

我有一个植根于接口并使用抽象基类实现的类层次结构。它看起来像这样：

interface Shape {
  boolean checkFlag();
}

abstract class AbstractShape implements Shape {
  private boolean flag = false;

  protected AbstractShape() { /* compute flag value */ }

  public final boolean checkFlag() { return flag; }
}

interface HasSides extends Shape { 
  int numberOfSides();
}

interface HasFiniteArea extends Shape { 
  double area();
}

class Square extends AbstractShape implements HasSides, HasFiniteArea {

} 

class Circle extends AbstractShape implements HasFiniteArea { 
}

/** etc **/

当我使用 VisualVM 对运行代码进行采样时，AbstractShape.checkFlag() 似乎从未内联，并且消耗总程序运行时间的 14%，这对于以下方法来说是令人厌恶的简单，即使对于如此频繁调用的方法也是如此。

我已在基类上将方法标记为final，并且（当前）所有实现“Shape”接口的类都扩展了AbstractShape。

我是否正确解释了 VisualVM 示例结果？有什么方法可以说服 JVM 内联此方法，还是我需要删除接口并只使用抽象基类？ （我不想这样做，因为层次结构包括像 HasFiniteArea 和 HasSides 这样的接口，这意味着层次结构没有完美的树形形式）

编辑：要清楚，这是一个在任何宇宙中的方法>应该内联。在 2 分钟执行期间，它被调用超过 4.2 亿次，并且由于它不是内联的并且仍然是虚拟调用，因此它占运行时的 14%。我要问的问题是是什么阻止了 JVM 内联此方法以及如何修复它？

Answer 1

这是来自维基百科的引用

一个常见的误解是将类或方法声明为final
通过允许编译器直接插入来提高效率
内联方法无论在哪里被调用。这并不完全正确。这
编译器无法执行此操作，因为类是在以下位置加载的
运行时并且可能与刚刚的版本不同
编译。此外，运行时环境和 JIT 编译器具有
有关已加载哪些类以及能够加载哪些类的信息
以便更好地决定何时内联、是否
方法是最终的。

另请参阅本文。

Answer 2

默认编译器阈值是 10000。 -XX:CompilerThreshold= 这意味着方法或循环（对于服务器 JVM）必须被调用至少 10000 次才能编译为本机代码。

编译后可以内联，但是调用堆栈确实显示了这一点。它足够聪明，知道内联代码来自另一个方法，并且您永远不会看到被截断的调用堆栈。

探查器尝试示例代码并分配时间。它并不总是做得很好，并且您得到的方法显然不是分配 CPU 时间的时间消费者。 VisualVM 是一个免费的分析器，它是用 Java 实现的。如果您使用像 YourKit 这样的分析器，您可以获得更准确的结果，因为它使用本机代码，例如不会产生垃圾。

Answer 3

经过大量的实验，我无法让 Sun JDK 6 在接口上调用时内联此方法。

幸运的是，涉及的调用站点数量有限，更改

public void paint(Shape shape) {
  if(shape.checkFlag()) { /* do stuff */ }
} 

为

public void paint(Shape shape) {
  if(((AbstractShape)shape).checkFlag()) { /* .. */ }
}

足以让 JVM 内联该方法。与原来的 6 分钟运行时间相比，相关计算的运行时间减少了 13%。

Answer 4

从我读到的有关旧版本 JVM 的文献中，通过将方法声明为 Final ，它将确定它将内联转换该方法。
现在，您不必将该方法指定为最终方法来优化代码。

您应该让 JVM 优化代码，并且仅当您明确不希望覆盖该方法时才将该方法设为最终方法。 JVM 可能不会使您的方法内联，因为考虑到应用程序代码的其余部分，它自己的优化速度更快。