跟我学（Effective Java 2）第64条:努力使失败保持原子性

第64条:努力使失败保持原子性

当对象抛出异常之后，通常我们期望这个对象仍然保持在一种定义良好的可用状态之中，即使失败是发生在执行某个操作的过程中间。对于受检的异常而言，这尤为重要，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法被称为具有失败原子性。

有几种途径可以实现这种效果。

1 最简单的办法莫过于设计一个不可变的对象（见第15条：使可变性最小化）。 如果对象是不可变的，失败原子性就是显然的。如果一个操作失败了，它可能会阻止创建新的对象，但是永远也不会使已有的对象保持在不一致的状态之中，因为当每个对象被创建之后它就处于一致的状态之中，以后也不会再发生变化。

2 对于在可变对象上执行操作的方法，获得失败原子性最常见的办法是，在执行操作之前检査参数的有效性（见第38条：检查参数的有效性）。 这可以使得在对象的状态被修改之前，先抛出适当的异常。

3 一种类似的获得失败原子性的办法是，调整计算处理过程的顺序，使得任何可能会失败的计算部分都在对象状态被修改之前发生。 如果对参数的检査只有在执行了部分计算之后才能进行，这种办法实际上就是上一种办法的自然扩展。

4 编写一段恢复代码(recovery code),由它来拦截操作过程中发生的失败，以及使对象回滚到操作开始之前的状态上。 这种办法主要用于永久性的(基于磁盘的(disk-based))数据结构。(很不常用)

5 在对象的一份临时拷贝上执行操作，当操作完成之后再用临时拷贝中的结果代替对象的内容。 如果数据保存在临时的数据结构中，计算过程会更加迅速，使用这种办法就是件很自然的事。例如，Collections.sort在执行排序之前，首先把它的输入列表转到一个数组中，以便降低在排序的内循环中访问元素所需要的开销。这是出于性能考虑的做法，但是，它增加了一项优势：即使排序失败，它也能保证输入列表保持原样。

虽然一般情况下都希望实现失败原子性，但并非总是可以做到。例如，如果两个线程企图在没有适当的同步机制的情况下，并发地修改同一个对象，这个对象就有可能被留在不一致的状态之中。因此，在捕获了ConcurrentModificationException异常之后再假设对象仍然是可用的，这就是不正确的。错误（相对于异常）通常是不可恢复的，当方法抛出错误时，它们不需要努力保持失败原子性。