java - 禁用时 Java 断言的性能拖累

Question

代码可以用断言编译，可以是 activated/deactivated when needed .

但是，如果我部署了一个带有断言的应用程序并且这些断言被禁用，那么在那里并被忽略会受到什么惩罚？

Answer 1

与传统观点相反，断言确实会影响运行时并可能影响性能。 在大多数情况下，这种影响可能很小，但在某些情况下可能很大。在运行时断言减慢速度的一些机制相当“平滑”和可预测(通常很小)，但下面讨论的最后一种方法(内联失败)很棘手，因为它是最大的潜在问题(你可能有一个数量级回归)并且它不平滑1。
分析
断言实现
说到分析 assert Java 中的功能，一件好事是它们在字节码/JVM 级别没有任何神奇之处。也就是说，它们是在 .class 中实现的。文件在(.java 文件)编译时使用标准 Java 机制，并且它们没有得到 JVM2 的任何特殊处理，而是依赖于适用于任何运行时编译代码的常用优化。
让我们快速浏览一下正好它们是如何在现代 Oracle 8 JDK 上实现的(但 AFAIK 几乎永远没有改变)。
使用单个断言采用以下方法:

public int addAssert(int x, int y) {
    assert x > 0 && y > 0;
    return x + y;
} 

...编译该方法并使用 javap -c foo.bar.Main 反编译字节码:

  public int addAssert(int, int);
    Code:
       0: getstatic     #17                 // Field $assertionsDisabled:Z
       3: ifne          22
       6: iload_1
       7: ifle          14
      10: iload_2
      11: ifgt          22
      14: new           #39                 // class java/lang/AssertionError
      17: dup
      18: invokespecial #41                 // Method java/lang/AssertionError."<init>":()V
      21: athrow
      22: iload_1
      23: iload_2
      24: iadd
      25: ireturn

字节码的前 22 个字节都与断言相关联。在前面，它会检查隐藏的静态 $assertionsDisabled如果为真，则跳过所有断言逻辑。否则，它只是以通常的方式进行两次检查，并构造并抛出 AssertionError()如果他们失败，则反对。
所以在字节码级别断言支持并没有什么特别的 - 唯一的技巧是 $assertionsDisabled字段，其中 - 使用相同的 javap输出 - 我们可以看到是一个 static final在类初始化时间初始化:

  static final boolean $assertionsDisabled;

  static {};
    Code:
       0: ldc           #1                  // class foo/Scrap
       2: invokevirtual #11                 // Method java/lang/Class.desiredAssertionStatus:()Z
       5: ifne          12
       8: iconst_1
       9: goto          13
      12: iconst_0
      13: putstatic     #17                 // Field $assertionsDisabled:Z

所以编译器创建了这个隐藏的 static final字段并基于公共(public)加载它 desiredAssertionStatus() 方法。
所以根本没有什么魔法。事实上，让我们自己尝试做同样的事情，用我们自己的静态 SKIP_CHECKS我们根据系统属性加载的字段:

public static final boolean SKIP_CHECKS = Boolean.getBoolean("skip.checks");

public int addHomebrew(int x, int y) {
    if (!SKIP_CHECKS) {
        if (!(x > 0 && y > 0)) {
            throw new AssertionError();
        }
    }
    return x + y;
}

在这里，我们只是直接写出断言在做什么(我们甚至可以组合 if 语句，但我们会尽量匹配断言)。让我们检查输出:

 public int addHomebrew(int, int);
    Code:
       0: getstatic     #18                 // Field SKIP_CHECKS:Z
       3: ifne          22
       6: iload_1
       7: ifle          14
      10: iload_2
      11: ifgt          22
      14: new           #33                 // class java/lang/AssertionError
      17: dup
      18: invokespecial #35                 // Method java/lang/AssertionError."<init>":()V
      21: athrow
      22: iload_1
      23: iload_2
      24: iadd
      25: ireturn

嗯，它几乎与断言版本相同的字节码。
断言成本
因此，我们几乎可以将“断言成本有多高”的问题简化为“基于 static final 条件的始终采用的分支跳过的代码成本有多高？”。好消息是，如果方法被编译，这些分支通常会被 C2 编译器完全优化掉。当然，即使在这种情况下，您仍然需要支付一些费用:

类文件更大，JIT 的代码也更多。

在 JIT 之前，解释版本可能会运行得更慢。

函数的完整大小用于内联决策，因此即使在禁用时，断言的存在也会影响此决策。

点 (1) 和 (2) 是在运行时编译 (JIT) 期间而不是在 java 文件编译时删除断言的直接结果。这是与 C 和 C++ 断言的主要区别(但作为交换，您可以决定在每次启动二进制文件时使用断言，而不是在该决定中进行编译)。
第(3)点可能是最关键的，很少被提及，也很难分析。基本思想是，JIT 在做出内联决策时使用了几个大小阈值 - 一个小阈值(~30 字节)，它几乎总是内联，另一个更大的阈值(~300 字节)从不内联。在阈值之间，是否内联取决于方法是否热，以及其他启发式，例如它是否已经在其他地方内联。
由于阈值基于字节码大小，因此断言的使用会显着影响这些决策 - 在上面的示例中，函数中 26 个字节中的 22 个完全与断言相关。特别是在使用许多小方法时，断言很容易将方法插入内联阈值。现在阈值只是启发式方法，因此在某些情况下将方法从内联更改为非内联可能会提高性能 - 但通常您想要更多而不是更少的内联，因为它是一种祖父优化，允许多次它发生。
减轻
解决此问题的一种方法是将大部分断言逻辑移至特殊函数，如下所示:

public int addAssertOutOfLine(int x, int y) {
    assertInRange(x,y);
    return x + y;
}

private static void assertInRange(int x, int y) {
    assert x > 0 && y > 0;
}

这编译为:

  public int addAssertOutOfLine(int, int);
    Code:
       0: iload_1
       1: iload_2
       2: invokestatic  #46                 // Method assertInRange:(II)V
       5: iload_1
       6: iload_2
       7: iadd
       8: ireturn

...因此将该函数的大小从 26 个字节减少到 9 个字节，其中 5 个与断言相关。当然，丢失的字节码刚刚移动到另一个函数，但这很好，因为它会在内联决策中单独考虑，并且当断言被禁用时 JIT 编译为无操作。
真正的编译时断言
最后，值得注意的是，您可以根据需要获得类似 C/C++ 的编译时断言。这些断言的开/关状态被静态编译到二进制文件中(在 javac 时间)。如果要启用断言，则需要一个新的二进制文件。另一方面，这种类型的断言在运行时是真正免费的。
如果我们更改自制软件 SKIP_CHECKS static final在编译时就知道了，像这样:

public static final boolean SKIP_CHECKS = true;

然后 addHomebrew编译为:

  public int addHomebrew(int, int);
Code:
   0: iload_1
   1: iload_2
   2: iadd
   3: ireturn

也就是说，断言没有留下任何痕迹。在这种情况下，我们可以真正说运行时成本为零。您可以通过使用一个包含 SKIP_CHECKS 的 StaticAssert 类来使其在整个项目中更可行。变量，你可以利用这个现有的 assert制作 1 行版本的糖:

public int addHomebrew2(int x, int y) {
    assert SKIP_CHECKS || (x > 0 && y > 0);
    return x + y;
}

同样，这会在 javac 时间编译为字节码，而没有断言的痕迹。您将不得不处理有关死代码的 IDE 警告(至少在 eclipse 中)。

1 在这里，我的意思是这个问题可能有零影响，然后在对周围代码进行小的无害更改后，它可能会突然产生很大的影响。基本上，由于“内联或不内联”决策的二元效应，各种惩罚级别被大量量化。
2 至少对于在运行时编译/运行断言相关代码的所有重要部分。当然，JVM 中有少量支持接受 -ea命令行参数并翻转默认断言状态(但如上所述，您可以使用属性以通用方式实现相同的效果)。