在Java中assert关键字是做什么的?

让我们看看编译后的字节码。

我们将得出结论:

public class Assert {
    public static void main(String[] args) {
        assert System.currentTimeMillis() == 0L;
    }
}

生成几乎完全相同的字节码:

public class Assert {
    static final boolean $assertionsDisabled =
        !Assert.class.desiredAssertionStatus();
    public static void main(String[] args) {
        if (!$assertionsDisabled) {
            if (System.currentTimeMillis() != 0L) {
                throw new AssertionError();
            }
        }
    }
}

其中Assert.class.desiredAssertionStatus()在命令行传递-ea时为true，否则为false。

我们使用System.currentTimeMillis()来确保它不会被优化掉(assert true;所做的那样)。

合成字段生成后，Java只需要在加载时调用Assert.class.desiredAssertionStatus()一次，然后将结果缓存到那里。参见:“静态合成”是什么意思?

我们可以用以下方法验证:

javac Assert.java
javap -c -constants -private -verbose Assert.class

在Oracle JDK 1.8.0_45中，生成了一个合成的静态字段(参见:“静态合成”是什么意思?):

static final boolean $assertionsDisabled;
  descriptor: Z
  flags: ACC_STATIC, ACC_FINAL, ACC_SYNTHETIC

与静态初始化项一起使用:

 0: ldc           #6                  // class Assert
 2: invokevirtual #7                  // Method java/lang Class.desiredAssertionStatus:()Z
 5: ifne          12
 8: iconst_1
 9: goto          13
12: iconst_0
13: putstatic     #2                  // Field $assertionsDisabled:Z
16: return

主要方法是:

 0: getstatic     #2                  // Field $assertionsDisabled:Z
 3: ifne          22
 6: invokestatic  #3                  // Method java/lang/System.currentTimeMillis:()J
 9: lconst_0
10: lcmp
11: ifeq          22
14: new           #4                  // class java/lang/AssertionError
17: dup
18: invokespecial #5                  // Method java/lang/AssertionError."<init>":()V
21: athrow
22: return

我们的结论是:

assert没有字节码级别的支持:它是Java语言的概念 assert可以用系统属性-Pcom.me很好地模拟。assert=true替换命令行上的-ea，并抛出新的AssertionError()。

断言允许检测代码中的缺陷。您可以打开断言进行测试和调试，而在程序处于生产状态时关闭断言。

既然你知道它是真的，为什么还要坚持呢?只有当一切都正常工作时，这才是正确的。如果程序有一个缺陷，它实际上可能不是真的。在过程早期检测到这一点可以让您知道哪里出了问题。

assert语句包含此语句以及可选的String消息。

assert语句的语法有两种形式:

assert boolean_expression;
assert boolean_expression: error_message;

下面是一些基本规则，它们控制着断言应该在哪里使用，不应该在哪里使用。断言应该用于:

验证私有方法的输入参数。不是公共方法。当传递坏参数时，公共方法应该抛出常规异常。 在程序的任何地方来确保一个事实的有效性，而这个事实几乎肯定是正确的。

例如，如果你确定它只会是1或2，你可以使用这样的断言:

...
if (i == 1)    {
    ...
}
else if (i == 2)    {
    ...
} else {
    assert false : "cannot happen. i is " + i;
}
...

在任何方法结束时验证后置条件。这意味着，在执行业务逻辑之后，您可以使用断言来确保变量或结果的内部状态与您所期望的一致。例如，打开套接字或文件的方法可以在末尾使用断言来确保确实打开了套接字或文件。

断言不应该用于:

验证公共方法的输入参数。由于断言可能并不总是被执行，因此应该使用常规异常机制。 对用户输入的内容验证约束。同上。 不应用于副作用。

例如，这不是一个正确的用法，因为断言在这里被用于调用doSomething()方法的副作用。

public boolean doSomething() {
...    
}
public void someMethod() {       
assert doSomething(); 
}

唯一可以证明这一点的情况是，当你试图找出断言是否在你的代码中启用时:

boolean enabled = false;    
assert enabled = true;    
if (enabled) {
    System.out.println("Assertions are enabled");
} else {
    System.out.println("Assertions are disabled");
}

下面是最常见的用例。假设你正在打开一个枚举值:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
}

只要你处理每一个案子，就没问题。但是有一天，有人会把fig添加到你的枚举中，而忘记把它添加到你的switch语句中。这将产生一个难以捕捉的错误，因为直到您离开switch语句后才会感受到其影响。但是如果你像这样写开关，你可以立即捕获它:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
  default:
    assert false : "Missing enum value: " + fruit;
}

总结一下(不仅仅是Java，很多语言都是如此):

“assert”主要被软件开发人员在调试过程中用作调试辅助。断言消息永远不会出现。许多语言提供了一个编译时选项，该选项将导致所有“断言”被忽略，用于生成“生产”代码。

"exceptions" are a handy way to handle all kinds of error conditions, whether or not they represent logic errors, because, if you run into an error-condition such that you cannot continue, you can simply "throw them up into the air," from wherever you are, expecting someone else out there to be ready to "catch" them. Control is transferred in one step, straight from the code that threw the exception, straight to the catcher's mitt. (And the catcher can see the complete backtrace of calls that had taken place.)

此外，该子例程的调用者不必检查子例程是否成功:“如果我们现在在这里，它一定成功了，因为否则它会抛出异常，我们现在就不会在这里!”这种简单的策略使得代码设计和调试变得非常非常容易。

异常方便地允许致命错误条件保持原样:“规则的异常”。而且，对于它们来说，由代码路径来处理，这也是“规则的例外……“高飞球!”

下面是我在Hibernate/SQL项目的服务器中编写的断言。一个实体bean有两个有效的布尔属性，称为isActive和isDefault。每个都可以有一个值“Y”或“N”或null，被视为“N”。我们希望确保浏览器客户端仅限于这三个值。所以，在这两个属性的setter中，我添加了这样的断言:

assert new HashSet<String>(Arrays.asList("Y", "N", null)).contains(value) : value;

注意以下几点。

This assertion is for the development phase only. If the client sends a bad value, we will catch that early and fix it, long before we reach production. Assertions are for defects that you can catch early. This assertion is slow and inefficient. That's okay. Assertions are free to be slow. We don't care because they're development-only tools. This won't slow down the production code because assertions will be disabled. (There's some disagreement on this point, which I'll get to later.) This leads to my next point. This assertion has no side effects. I could have tested my value against an unmodifiable static final Set, but that set would have stayed around in production, where it would never get used. This assertion exists to verify the proper operation of the client. So by the time we reach production, we will be sure that the client is operating properly, so we can safely turn the assertion off. Some people ask this: If the assertion isn't needed in production, why not just take them out when you're done? Because you'll still need them when you start working on the next version.

Some people have argued that you should never use assertions, because you can never be sure that all the bugs are gone, so you need to keep them around even in production. And so there's no point in using the assert statement, since the only advantage to asserts is that you can turn them off. Hence, according to this thinking, you should (almost) never use asserts. I disagree. It's certainly true that if a test belongs in production, you should not use an assert. But this test does not belong in production. This one is for catching a bug that's not likely to ever reach production, so it may safely be turned off when you're done.

顺便说一句，我可以这样写:

assert value == null || value.equals("Y") || value.equals("N") : value;

对于只有三个值是可以的，但是如果可能值的数量变大，HashSet版本就会变得更方便。我选择HashSet版本来说明我关于效率的观点。

断言是可以被关闭的检查。它们很少被使用。为什么?

它们不能用于检查公共方法参数，因为您无法控制它们。 它们不应该用于简单的检查，如result != null，因为这样的检查非常快，几乎没有什么可以保存。

那么，还剩下什么呢?昂贵的条件检查是真实的。像rb树这样的数据结构的不变量就是一个很好的例子。实际上，在JDK8的ConcurrentHashMap中，对于TreeNodes有一些这样有意义的断言。

您确实不希望在生产环境中启用它们，因为它们很容易控制运行时间。 您可能希望在测试期间打开或关闭它们。 在处理代码时一定要打开它们。

有时候，支票不是很贵，但与此同时，你很确定，它会通过。在我的代码中，有例如，

assert Sets.newHashSet(userIds).size() == userIds.size();

我很确定我刚刚创建的列表有独特的元素，但我想记录并再次检查它。