一个真实的例子，来自一个stack类(来自Java文章中的断言)

public int pop() {
   // precondition
   assert !isEmpty() : "Stack is empty";
   return stack[--num];
}

断言用于检查后置条件和“永不失败”的前提条件。正确的代码应该永远不会使断言失败;当它们触发时，它们应该指出一个错误(希望是在接近问题的实际位置的地方)。

断言的一个例子可能是检查一组特定的方法是否以正确的顺序被调用(例如，在迭代器中hasNext()在next()之前被调用)。

断言(通过assert关键字)是在Java 1.4中添加的。它们用于验证代码中不变量的正确性。它们永远不应该在生产代码中触发，并且指示了代码路径的错误或误用。它们可以在运行时通过java命令上的-ea选项激活，但默认情况下不会打开。

一个例子:

public Foo acquireFoo(int id) {
  Foo result = null;
  if (id > 50) {
    result = fooService.read(id);
  } else {
    result = new Foo(id);
  }
  assert result != null;

  return result;
}

断言主要用于调试应用程序，或者用于替换某些应用程序的异常处理，以检查应用程序的有效性。

断言在运行时工作。这里有一个简单的例子，可以非常简单地解释整个概念——assert关键字在Java中做什么?(WikiAnswers)。

Assert是一个关键字。它在JDK 1.4中引入。这是两种类型的断言

非常简单的断言语句 简单的断言语句。

默认情况下，所有assert语句都不会被执行。如果assert语句接收到false，则它将自动引发断言错误。

让我们假设您要编写一个控制核电站的程序。很明显，即使是最微小的错误也可能导致灾难性的结果，因此您的代码必须是无bug的(为了论证，假设JVM是无bug的)。

Java不是一种可验证的语言，这意味着:你不能计算出你的操作结果会是完美的。这样做的主要原因是指针:它们可以指向任何地方，也可以指向任何地方，因此它们不能被计算为这个确切的值，至少在合理的代码范围内不能。对于这个问题，没有办法证明您的代码在整体上是正确的。但你能做的是证明你至少能在bug发生时找到它。

此思想基于契约式设计(Design-by-Contract, DbC)范式:首先定义(具有数学精度)您的方法应该做什么，然后在实际执行期间通过测试来验证这一点。例子:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
  return a + b;
}

虽然这很明显可以正常工作，但大多数程序员不会看到其中隐藏的bug(提示:Ariane V因为类似的bug而崩溃)。现在DbC定义您必须始终检查函数的输入和输出，以验证它是否正确工作。Java可以通过断言来做到这一点:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
    assert (Integer.MAX_VALUE - a >= b) : "Value of " + a + " + " + b + " is too large to add.";
  final int result = a + b;
    assert (result - a == b) : "Sum of " + a + " + " + b + " returned wrong sum " + result;
  return result;
}

如果这个函数现在失败了，您会注意到它。你会知道你的代码中有问题，你知道它在哪里，你知道是什么引起的(类似于异常)。更重要的是:当它发生时停止正确执行，以防止任何进一步的代码使用错误的值，并可能对它所控制的任何东西造成损害。

Java异常是一个类似的概念，但它们不能验证所有内容。如果需要更多的检查(以降低执行速度为代价)，则需要使用断言。这样做会使代码膨胀，但最终可以在短得惊人的开发时间内交付产品(越早修复bug，成本就越低)。此外，如果代码中有任何错误，您将检测到它。不可能出现漏洞并在以后引起问题。

这仍然不能保证代码没有错误，但它比通常的程序更接近于这一点。

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

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;
}

断言是用于捕获代码中的错误的开发阶段工具。它们被设计为易于删除，因此它们不会存在于生产代码中。因此断言不是您交付给客户的“解决方案”的一部分。它们是内部检查，以确保你所做的假设是正确的。最常见的例子是测试是否为空。很多方法都是这样写的:

void doSomething(Widget widget) {
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

在这样的方法中，小部件通常不应该是空的。所以如果它是空的，在你的代码中有一个bug，你需要追踪。但是上面的代码永远不会告诉你这一点。因此，在编写“安全”代码的善意努力中，您也隐藏了一个错误。这样写代码会更好:

/**
 * @param Widget widget Should never be null
 */
void doSomething(Widget widget) {
  assert widget != null;
  widget.someMethod(); // ...
    ... // do more stuff with this widget
}

这样，您一定能尽早发现这个错误。(在合同中指定这个参数永远不应该为空也是有用的。)在开发过程中测试代码时，一定要打开断言。(说服你的同事这样做通常也很困难，我觉得这很烦人。)

现在，您的一些同事会反对这段代码，认为您仍然应该放入null检查，以防止生产中出现异常。在这种情况下，断言仍然有用。你可以这样写:

void doSomething(Widget widget) {
  assert widget != null;
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

这样，您的同事就会高兴地看到产品代码有空检查，但在开发过程中，当小部件为空时，您就不再隐藏错误了。

这里有一个真实的例子:我曾经写过一个方法，比较两个任意值是否相等，其中任何一个值都可以为空:

/**
 * Compare two values using equals(), after checking for null.
 * @param thisValue (may be null)
 * @param otherValue (may be null)
 * @return True if they are both null or if equals() returns true
 */
public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = thisValue.equals(otherValue);
  }
  return result;
}

这段代码在thisValue不为空的情况下委托equals()方法的工作。但它假设equals()方法通过正确处理空参数正确地实现了equals()的契约。

一位同事反对我的代码，告诉我我们的许多类都有不测试null的equals()方法，所以我应该把这个检查放到这个方法中。这是否是明智的，或者我们是否应该强制错误，这样我们就可以发现并修复它，这是有争议的，但我听从了我同事的意见，放入了一个空检查，我已经标记了一个注释:

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = otherValue != null && thisValue.equals(otherValue); // questionable null check
  }
  return result;
}

这里的额外检查other != null仅在equals()方法不能按照其契约要求检查null时才有必要。

我没有与同事就让有bug的代码留在代码库中是否明智进行毫无结果的争论，而是简单地在代码中放入了两个断言。这些断言会让我知道，在开发阶段，如果我们的一个类不能正确地实现equals()，所以我可以修复它:

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
    assert otherValue == null || otherValue.equals(null) == false;
  } else {
    result = otherValue != null && thisValue.equals(otherValue);
    assert thisValue.equals(null) == false;
  }
  return result;
}

需要记住的要点如下:

Assertions are development-phase tools only. The point of an assertion is to let you know if there's a bug, not just in your code, but in your code base. (The assertions here will actually flag bugs in other classes.) Even if my colleague was confident that our classes were properly written, the assertions here would still be useful. New classes will be added that might fail to test for null, and this method can flag those bugs for us. In development, you should always turn assertions on, even if the code you've written doesn't use assertions. My IDE is set to always do this by default for any new executable. The assertions don't change the behavior of the code in production, so my colleague is happy that the null check is there, and that this method will execute properly even if the equals() method is buggy. I'm happy because I will catch any buggy equals() method in development.

此外，您应该通过放入一个将失败的临时断言来测试断言策略，这样您就可以确定通过日志文件或输出流中的堆栈跟踪来通知您。

Assert在开发时非常有用。当代码正常工作时，某些事情就不能发生。它易于使用，并且可以永远保留在代码中，因为在现实生活中它将被关闭。

如果这种情况在现实生活中有任何可能发生，那么您必须处理它。

我喜欢它，但不知道如何在Eclipse/Android/ADT中打开它。即使在调试时，它也似乎是关闭的。(有一个关于这个的线程，但它指的是“Java虚拟机”，它不会出现在ADT运行配置中)。

基本上，“断言为真”会通过，“断言为假”会失败。让我们看看这是如何工作的:

public static void main(String[] args)
{
    String s1 = "Hello";
    assert checkInteger(s1);
}

private static boolean checkInteger(String s)
{
    try {
        Integer.parseInt(s);
        return true;
    }
    catch(Exception e)
    {
        return false;
    }
}

在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()。

除了这里提供的所有很棒的答案之外，官方Java SE 7编程指南还提供了关于使用assert的非常简洁的手册;通过几个准确的例子，说明了何时使用断言是一个好主意(重要的是，也是坏主意)，以及它与抛出异常有何不同。

Link

默认情况下，断言是禁用的。要启用它们，我们必须使用-ea选项运行程序(粒度可以改变)。例如，java -ea AssertionsDemo。

使用断言有两种格式:

简单:如。维护1 = = 2;//这将引发AssertionError。 更好的方法:断言1==2:“不可能..1不等于2”; 这将引发AssertionError，并显示给定的消息，因此更好。虽然实际的语法是断言expr1:expr2，其中expr2可以是返回值的任何表达式，但我更多地使用它只是为了打印消息。

什么时候应该使用Assert ?

很多很好的答案解释了assert关键字的作用，但很少回答真正的问题，“在现实生活中什么时候应该使用assert关键字?”答案是:

几乎从来没有

断言，作为一个概念，是很棒的。好的代码有很多if(…)throw…语句(以及它们的亲戚，如对象。requireNonNull和Math.addExact)。然而，某些设计决策极大地限制了assert关键字本身的效用。

assert关键字背后的驱动思想是不成熟的优化，其主要特性是能够轻松地关闭所有检查。事实上，断言检查在默认情况下是关闭的。

然而，在生产中继续执行不变检查是非常重要的。这是因为完美的测试覆盖率是不可能的，所有的产品代码都会有错误，而断言应该有助于诊断和减轻这些错误。

因此，if(…)的使用抛出…应该是首选的，就像检查公共方法的参数值和抛出IllegalArgumentException时需要它一样。

偶尔，人们可能会被诱惑编写一个不变检查，它确实需要很长时间来处理(并且经常被调用，以至于它很重要)。然而，这样的检查将减缓测试，这也是不可取的。这种耗时的检查通常被写成单元测试。然而，出于这个原因，有时使用assert是有意义的。

不要使用assert，因为它比if(…)throw…(我非常痛苦地说，因为我喜欢干净和漂亮)。如果您无法控制自己，并且可以控制应用程序的启动方式，那么可以随意使用断言，但始终在生产环境中启用断言。不可否认，这是我倾向于做的事情。我正在推动一个lombok注释，它将导致assert的行为更像if(…)throw ....请在这里投票。

(咆哮:JVM开发者是一群糟糕的、过早优化的编码员。这就是为什么你会在Java插件和JVM中听到这么多安全问题。他们拒绝在产品代码中包含基本的检查和断言，而我们正在继续为此付出代价。)

下面是我在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版本来说明我关于效率的观点。

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

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

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");
}

总结一下(不仅仅是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.)

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

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

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

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

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

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

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

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

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

这是另一个例子。我写了一个方法来查找两个排序数组中值的中位数。该方法假设数组已经排序。出于性能考虑，它不应该首先对数组排序，甚至不应该检查以确保它们已排序。然而，对未排序的数据调用此方法是一个严重的错误，我们希望在开发阶段尽早发现这些错误。下面是我处理这些看似矛盾的目标的方法:

public static int medianOf(int[] a, int[] b) {
  assert assertionOnlyIsSorted(a);      // Assertion is order n
  assert assertionOnlyIsSorted(b);
  ... // rest of implementation goes here. Algorithm is order log(n)
}

public static boolean assertionOnlyIsSorted(int[] array) {
  for (int i=1; i<array.length; ++i) {
    if (array[i] < array[i-1]) {
      return false;
    }
    return true;
  }
}

这样，缓慢的测试只在开发阶段执行，在开发阶段，速度没有捕获错误重要。您希望medianOf()方法具有log(n)性能，但“is sorted”测试是o (n)。因此，我将其放在断言中，以限制其在开发阶段的使用，并为其命名，以明确表示它不适合生产。

这样我就两全其美了。在开发过程中，我知道任何不正确地调用这个函数的方法都会被捕获并修复。而且我知道这样做的缓慢测试不会影响生产中的性能。(这也很好地说明了为什么要在生产环境中关闭断言，而在开发环境中启用断言。)

我不知道Java中这个特性背后的历史。但是我有一个关于断言可以用来做什么的想法，我认为在这个帖子中没有提到过。

假设你有一个枚举，你打开它:(†)

public enum Veggie {
    CAULIFLOWER,
    CARROT,
}

// Another class
switch (veggie) {
    case CAULIFLOWER: value = 5;
    case CARROT: value = 3;
}

†:也许优秀的Java编译器/工具会静态地捕获丢失的枚举值。在这种情况下，想象一下你发现了一些bug并修复了它。然后，您可以使用下面描述的技术在代码中适当地添加回归测试。

这里没有好的默认情况。所以你要确保你覆盖了所有的值。当你添加一个新的enum变量时，你要确保你更新了switch块:

public enum Veggie {
    CAULIFLOWER,
    CARROT,
    TOMATO,
}

但事实证明，当用户在web应用程序中加载特定视图时，这段代码会被调用。尽管存在这个错误，视图仍然可以持续存在:这将是一个bug，但不值得干扰视图的加载(让我们说用户只是看到了一些错误的数字)。所以你只需要记录一个警告:

switch (veggie) {
    case CAULIFLOWER: value = 5;
    case CARROT: value = 3;
    default: nonExhaustiveMatchOnEnum();
// […]
public static void nonExhaustiveMatchOnEnum() {
    String errorMessage: "Missing veggie";
    logger.warn(errorMessage);
}

但是当你在开发代码时，你确实希望这个错误立即失败——开发者可以在五分钟内修复这个错误，而不像你的web应用程序的用户。

所以你可以添加一个assert false:

public static void nonExhaustiveMatchOnEnum() {
    String errorMessage: "Missing veggie";
    assert false : errorMessage;
    logger.warn(errorMessage);
}

现在，应用程序将在本地崩溃，但只在生产中记录一个警告(假设您在本地使用java -ea，而不是在生产中)。