为那些还不清楚它的人，Python的assert是用来检查一个条件，如果它为真，就不做任何事。如果它为假，则会抛出AssertError并且包含错误信息。例如：
py>x = 23
py>assert x >0, "x is not zero or negative"
py>assert x%2 == 0, "x is not an even number"
Traceback (most recent call last):
File "", line 1, in
AssertionError: x is not an even number
很多人用assert作为一个很快和容易的方法来在参数错误的时候抛出异常。但这样做是错的，非常错误，有两个原因。首先AssertError不是在测试参数时应该抛出的错误。你不应该像这样写代码：
if not isinstance(x, int):
raise AssertionError("not an int")
你应该抛出TypeError的错误，assert会抛出错误的异常。
但是，更危险的是，有一个关于assert的困扰：它可以被编译好然后从来不执行，如果你用 –O 或 –oo
选项运行Python，结果不保证assert表达式会运行到。当适当的使用assert时，这是未来，但是当assert不恰当的使用时，它会让代码用
-O执行时出错。
那什么时候应该使用assert？没有特定的规则，断言应该用于：
防御型的编程
运行时检查程序逻辑
检查约定
程序常量
检查文档
（在测试代码的时候使用断言也是可接受的，是一种很方便的单元测试方法，你接受这些测试在用-O标志运行时不会做任何事。我有时在代码里使用
assert False来标记没有写完的代码分支，我希望这些代码运行失败。尽管抛出NotImplementedError可能会更好。）
关于断言的意见有很多，因为它能确保代码的正确性。如果你确定代码是正确的，那么就没有用断言的必要了，因为他们从来不会运行失败，你可以直接移除这些断言。如果你确定检查会失败，那么如果你不用断言，代码就会通过编译并忽略你的检查。
在以上两种情况下会很有意思，当你比较肯定代码但是不是绝对肯定时。可能你会错过一些非常古怪的情况。在这个情况下，额外的运行时检查能帮你确保任何错误都会尽早地被捕捉到。
另一个好的使用断言的方式是检查程序的不变量。一个不变量是一些你需要依赖它为真的情况，除非一个bug导致它为假。如果有bug，最好能够尽早发现，所以我们为它进行一个测试，但是又不想减慢代码运行速度。所以就用断言，因为它能在开发时打开，在产品阶段关闭。
一个非变量的例子可能是，如果你的函数希望在它开始时有数据库的连接，并且承诺在它返回的时候仍然保持连接，这就是函数的不变量：
Python
def some_function(arg):
assert not DB.closed()
... # code goes here
assert not DB.closed()
return result
断言本身就是很好的注释，胜过你直接写注释：
# when we reach here, we know that n >2
你可以通过添加断言来确保它：
assert n >2
断言也是一种防御型编程。你不是让你的代码防御现在的错误，而是防止在代码修改后引发的错误。理想情况下，单元测试可以完成这样的工作，可是需要面
对的现实是，它们通常是没有完成的。人们可能在提交代码前会忘了运行测试代码。有一个内部检查是另一个阻挡错误的防线，尤其是那些不明显的错误，却导致了
代码出问题并且返回错误的结果。
加入你有一些if…elif 的语句块，你知道在这之前一些需要有一些值：
# target is expected to be one of x, y, or z, and nothing else.
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
run_z_code()
假设代码现在是完全正确的。但它会一直是正确的吗？依赖的修改，代码的修改。如果依赖修改成 target = w
会发生什么，会关系到run_w_code函数吗？如果我们改变了代码，但没有修改这里的代码，可能会导致错误的调用 run_z_code
函数并引发错误。用防御型的方法来写代码会很好，它能让代码运行正确，或者立马执行错误，即使你在未来对它进行了修改。
在代码开头的注释很好的一步，但是人们经常懒得读或者更新注释。一旦发生这种情况，注释会变得没用。但有了断言，我可以同时对代码块的假设书写文档，并且在它们违反的时候触发一个干净的错误
assert target in (x, y, z)
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
assert target == z
run_z_code()
这样，断言是一种防御型编程，同时也是一种文档。我想到一个更好的方案：
if target == x:
run_x_code()
elif target == y:
run_y_code()
elif target == z:
run_z_code()
else:
# This can never happen. But just in case it does...
raise RuntimeError("an unexpected error occurred")
按约定进行设计是断言的另一个好的用途。我们想象函数与调用者之间有个约定，比如下面的：
“如果你传给我一个非空字符串，我保证传会字符串的第一个字母并将其大写。”
如果约定被函数或调用这破坏，代码就会出问题。我们说函数有一些前置条件和后置条件，所以函数就会这么写：
def first_upper(astring):
assert isinstance(astring, str) and len(astring) >0
result = astring[0].upper()
assert isinstance(result, str) and len(result) == 1
assert result == result.upper()
return result
按约定设计的目标是为了正确的编程，前置条件和后置条件是需要保持的。这是断言的典型应用场景，因为一旦我们发布了没有问题的代码到产品中，程序会是正确的，并且我们能安全的移除检查。
下面是建议的不要用断言的场景：
不要用它测试用户提供的数据
不要用断言来检查你觉得在你的程序的常规使用时会出错的地方。断言是用来检查非常罕见的问题。你的用户不应该看到任何断言错误，如果他们看到了，这是一个bug，修复它。
有的情况下，不用断言是因为它比精确的检查要短，它不应该是懒码农的偷懒方式。
不要用它来检查对公共库的输入参数，因为它不能控制调用者，所以不能保证调用者会不会打破双方的约定。
不要为你觉得可以恢复的错误用断言。换句话说，不用改在产品代码里捕捉到断言错误。
不要用太多断言以至于让代码很晦涩。
一、assertion的意义和用法J2SE 1.4在语言上提供了一个新特性，就是assertion功能，它是该版本在Java语言方面最大的革新。
从理论上来说，通过 assertion方式可以证明程序的正确性，但是这是一项相当复杂的工作，目前还没有太多的实践意义。
在实现中，assertion就是在程序中的一条语句，它对一个boolean表达式进行检查，一个正确程序必须保证这个boolean表达式的值为true；如果该值为false，说明程序已经处于不正确的状态下，系统将给出警告或退出。
一般来说，assertion用于保证程序最基本、关键的正确性。assertion检查通常在开发和测试时开启。为了提高性能，在软件发布后，assertion检查通常是关闭的。
1、语法表示
在语法上，为了支持assertion，Java增加了一个关键字assert。它包括两种表达式，分别如下：
assert expression1
assert expression1:expression2
在两种表达式中，expression1表示一个boolean表达式， expression2表示一个基本类型或者是一个对象(Object)，基本类型包括boolean,char,double,float,int和 long。由于所有类都为Object的子类，因此这个参数可以用于所有对象。
2、含义
在运行时，如果关闭了assertion功能，这些语句将不起任何作用。如果打开了assertion功能，那么expression1的值将被计算，如果它的值为false，该语句强抛出一个AssertionError对象。
如果assertion语句包括expression2参数，程序将计算出 expression2的结果，然后将这个结果作为AssertionError的构造函数的参数，来创建AssertionError对象，并抛出该对 象；如果expression1值为true，expression2将不被计算。
一种特殊情况是，如果在计算表达式时，表达式本身抛出Exception，那么assert将停止运行，而抛出这个Exception。
3、编译
由于assert是一个新关键字，使用老版本的JDK是无法编译带有assert的 源程序。因此，我们必须使用JDK1.4(或者更新)的Java编译器，在使用Javac命令时，我们必须加上-source 1.4作为参数。-source 1.4表示使用JDK 1.4版本的方式来编译源代码，否则编译就不能通过，因为缺省的Javac编译器使用JDK1.3的语法规则。
大家在使用eclipse,jbuilder等IDE工具的时候,要注意编译器的版本,使用的jre,不等于是javac 的版本
一个简单的例子如下：javac -source 1.4 AssertTest.java
4、运行
由于我们可以选择开启assertion功能，或者不开启，另外我们还可以开启一部 分类或包的assertion功能。通过这些选项，我们可以过滤所有我们不关心的类，只选择我们关心的类或包来观察。
参数 -esa 和 -dsa：
它们含义为开启(关闭)系统类的assertion功能。由于新版本的Java的系统类中，也使了assertion语句，因此如果用户需要观察它们的运行情况，就需要打开系统类的assertion功能 ，我们可使用-esa参数打开，使用 -dsa参数关闭。
-esa和-dsa的全名为-enablesystemassertions和-disenablesystemassertions，全名和缩写名有同样的功能。
参数 -ea和-ea：
它们含义为开启(关闭)用户类的assertion功能：通过这个参数，用户可以打 开某些类或包的assertion功能，同样用户也可以关闭某些类和包的assertion功能。打开assertion功能参数为-ea；如果不带任何 参数，表示打开所有用户类；如果带有包名称或者类名称，表示打开这些类或包；如果包名称后面跟有三个点，代表这个包及其子包；如果只有三个点，代表无名 包。关闭assertion功能参数为-da，使用方法与-ea类似。
-ea和-da的全名为-enableassertions和-disenableassertions，全名和缩写名有同样的功能。下面表示了参数及其含义。
参数 例子 说明
-ea java -ea 打开所有用户类的assertion
-da java -da 关闭所有用户类的assertion
-ea: java -ea:MyClass1 打开MyClass1的assertion
-da: java -da: MyClass1 关闭MyClass1的assertion
-ea: java -ea:pkg1 打开pkg1包的assertion
-da: java -da:pkg1 关闭pkg1包的assertion
-ea:... java -ea:... 打开缺省包(无名包)的assertion
-da:... java -da:... 关闭缺省包(无名包)的assertion
-ea:... java -ea:pkg1... 打开pkg1包和其子包的assertion
-da:... java -da:pkg1... 关闭pkg1包和其子包的assertion
-esa java -esa 打开系统类的assertion
-dsa java -dsa 关闭系统类的assertion
综合使用 java -dsa:MyClass1:pkg1 关闭MyClass1和pkg1包的assertion
其中...代表，此包和其子包的含义。例如我们有两个包为pkg1和pkg1.subpkg。
那么pkg1...就代表pkg1和pkg1.subpkg两个包。
另外，Java为了让程序也能够动态开启和关闭某些类和包的assertion功能，Java修该了Class和ClassLoader的实现，增加了几个用于 *** 作assert的API。下面简单说明一下几个API的作用。
ClassLoader类中的几个相关的API:
setDefaultAssertionStatus:
用于开启/关闭assertion功能
setPackageAssertionStatus:
用于开启/关闭某些包的assertion功能
setClassAssertionStatus:
用于开启/关闭某些类的assertion功能
clearAssertionStatus：
用于关闭assertion功能
二、assertion的设计问题
首先，我们认为assertion是必要的。因为，如果没有统一的assertion机制，Java程序通常使用if-then-else或者switch-case语句进行assertion检查，而且检查的数据类型也不完全相同。
assertion机制让Java程序员用统一的方式处理assertion问题， 而不是按自己的方式处理。另外，如果用户使用自己的方式进行检查，那么这些代码在发布以后仍然将起作用，这可能会影响程序的性能。而从语言言层次支持 assertion功能，这将把assertion对性能带来的负面影响降到最小。
Java是通过增强一个关键字assert实现支持assertion，而不是 使用一个库函数支持，这说明Java认为assertion对于语言本身来说是非常重要的。C语言就是 通过Assert.h函数库实现断言的支持。
Java的assertion的开启也和C语言不太一样，我们都知道在C语言中，assertion的开启是在编译时候决定的。当我们使用debug方式编译程序时候，assertion被开启，而使用release方式编译时候，assertion自动被关闭。
而Java的assertion却是在运行的时候进行决定的。其实，这两种方式是各有优缺点。如果采用编译时决定方式，开发人员将处理两种类型的目标码，debug版本和release版本，这加大了文档管理的难度，但是提高了代码的运行效率。
Java采用运行时决定的方式，这样所有的assertion信息将置于目标代码 中，同一目标代码可以选择不同方式运行，增强目标代码的灵活性，但是它将牺牲因为assertion而引起一部分性能损失。
另外，我们注意到AssertionError作为Error的一个子类，而不 是RuntimeException。Error代表一些异常的错误，通常是不可以恢复的，而 RuntimeException强调该错误在运行时才发生的特点。AssertionError通常为非常关键的错误，这些错误往往是不容易恢复的，而且assertion机制也不鼓励程序员对这种错误进行恢复。
三、assertion与继承
如果一个assert语句在父类，而当它的子类调用它时，该assert为false。父类的assert语句将只有在父类的assert开启才起作用，如果仅仅开启子类的assert，父类的assert仍然不运行。因此，assert语句不具有继承功能。
四、assertion的使用
assertion的使用是一个复杂的问题，通常来说，assertion用于检查一些关键的值，并且这些值对整个程序，或者局部功能的完成有很大的影响，并且这种错误不容易恢复的。
assertion表达式应该短小、易懂，如果需要评估复杂的表达式，应该使用函数计算。以下是一些使用assertion的情况的例子，这些方式可以让java程序的可靠性更高。
检查控制流； 在if-then-else和swith-case语句中，我们可以在不应该发生的控制支流上加上assert false语句。如果这种情况发生了，assert能够检查出来。
在私有函数计算前，检查输入参数是否有效；对于一私有些函数，要求输入满足一些特定的条件，那么我们可以在函数开始处使用assert进行参数检查。
对于公共函数，我们通常不使用assertion检查，因为一般来说，公共函数必须对无效的参数进行检查和处理。而私有函数往往是直接使用的。例如：某函数可能要求输入的参数必须不为null。那么我们可以在函数的一开始加上：
assert parameter1!=null : "paramerter is null in test method"
在函数计算后，检查函数结果是否有效；对于一些计算函数，函数运行完成后，某些值需要保证一定的性质，因此我们可以通过assert检查该值。例如，我们有一个计算绝对值的函数，那么我们就可以在函数的结果处，加上一个语句：
assert value>=0:"Value should be bigger than 0:"+value
通过这种方式，我们可以对函数计算完的结果进行检查。检查程序不变量；有些程序中，存在一些不变量，在程序的运行生命周期，这些不变量的值都是不变的。这些不变量可能是一个简单表达式，也可能是一个复杂的表达式。
对于一些关键的不变量，我们可以通过assert进行检查。例如，在一个财会系统中，公司的支出和收入必须保持一定的平衡关系，因此我们可以编写一个表达式检查这种平衡关系，如下表示：
private boolean isBalance() {…… }
在这个系统中，在一些可能影响这种平衡关系的方法的前后，我们都可以加上assert验证：
assert isBalance():"balance is destoried"
五、补充
必须清楚AssertionError是继承自Error得，因此你可以不再程序中catch它的，当然你也可以在程序中catch它然后程序可以继续执行。
例如：
public class AssertTest
{
public static void main(String[] args)
{
AssertTest at = new AssertTest()
try
{
at.assertMe(true)
at.assertMe(false)
}
catch(AssertionError ae)
{
System.out.println("AsseriontError catched")
}
System.out.println("go on")
}
private void assertMe(boolean boo)
{
assert boo?true:false
System.out.println("true condition")
}
}
Assert最好不要滥用，原因是assert并不一定都是enable的，下面两种情况就不应该用assert
不要再public的方法里面检查参数是不是为null之类的 *** 作
例如public int get(String s)
{
assert s != null
}
如果需要检查也最好通过if s = null 抛出NullPointerException来检查
不要用assert来检查方法 *** 作的返回值来判断方法 *** 作的结果
例如 assert list.removeAll()这样看起来好像没有问题 但是想想如果assert 被disable呢，那样他就不会被执行了 所以removeAll() *** 作就没有被执行 可以这样代替
boolean boo = list.removeAl()
assert boo
天官赐福博客园 首页 联系 管理
随笔 - 18 文章 - 0 评论 - 0 阅读 - 1354
3.1 共享数据带来的问题
当涉及到共享数据时，问题很可能是因为修改共享数据所导致。如果共享数据是只读的，那么只读 *** 作不会影响到数据，所以所有线程都会获得同样的数据。但是，当一个或多个线程要修改共享数据时，就会产生很多麻烦。
不变量：双链表中每个节点都有一个指针指向列表中下一个节点，还有一个指针指向前一个节点。其中不变量就是：节点A中指向“下一个”节点B的指针，还有前向指针。为了从列表中删除一个节点，其两边节点的指针都需要更新。当其中一边更新完成时，不变量就被破坏了，直到另一边也完成更新；在两边都完成更新后，不变量就又稳定了。
从一个列表中删除一个节点的步骤如下：
找到要删除的节点N
更新前一个节点指向N的指针，让这个指针指向N的下一个节点
更新后一个节点指向N的指针，让这个指正指向N的前一个节点
删除节点N
图3.1 从一个双链表中删除一个节点
图中b和c在相同的方向上指向和原来已经不一致了，这就破坏了不变量。破坏不变量的后果是多样的，当其他线程按从左往右的顺序来访问列表时，它将跳过被删除的节点；在一方面，如有第二个线程尝试删除图中右边的节点，那么可能会让数据结构产生永久性的损坏，使程序崩溃。无论结果如何，都是并行代码常见错误：条件竞争。
3.1.1 条件竞争
并发中竞争条件的形成，取决于一个以上线程的相对执行顺序，每个线程都抢着完成自己的任务。
恶性条件竞争：当不变量遭到破坏时，才会产生条件竞争，比如双向链表的例子。并发中对数据的条件竞争通常表示为恶性条件竞争。
3.1.2 避免恶性条件竞争
这里提供一些方法来解决恶性条件竞争：
最简单的办法就是对数据结构采用某种保护机制，确保只有进行修改的线程才能看到不变量被破坏时的中间状态；
另一个选择是对数据结构和不变量的设计进行修改，修改完的结构必须能完成一系列不可分割的变化，也就是保证每个不变量保持稳定的状态，这就是所谓的无锁编程。
另一种处理条件竞争的方式是，使用事务的方式去处理数据结构的更新。所需的一些数据和读取都存储在事务日志中，然后将之前的 *** 作合为一步，再进行提交。当数据结构被另一个线程
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）