ConcurrentModificationException源码逐条解析

一家之言 姑妄言之 絮絮叨叨 不足为训

ConcurrentModificationException类注释翻译:

   当不允许修改时，已经检测到对象并发修改的方法可能会抛出此异常。
   例如，当一个线程在集合上迭代时，通常不允许另一个线程修改集合。一般来说，迭代的结果在这种情况下是没有定义的。如果检测到上述行为，某些迭代器实现(包括JRE提供的所有通用集合实现)可能会选择抛出此异常。这样做的迭代器被称为故障快速fail-fast迭代器，因为它们快速而干净地失败了，而不是在将来某个不确定的时间冒着任意的、不确定的行为的风险。
   请注意，此异常并不总是表示对象已被其他线程并发修改。如果单个线程发出的一系列方法调用违反了对象的契约，则对象可能会抛出此异常。例如，如果线程在使用故障快速fail-fast迭代器遍历集合时直接修改集合，迭代器将抛出此异常。
   注意，快速故障行为fail-fast不能得到保证，因为通常来说，在非同步并发修改的情况下，不可能做出任何严格的保证。快速故障操作会在最大努力的基础上抛出ConcurrentModificationException异常。因此，编写一个依赖于这个异常来保证其正确性的程序是错误的：ConcurrentModificationException应该只用于检测bug。

---

笔者废话：

   其实这个异常类的注释已经写得很不错了，但是由于笔者翻译的问题（不敢加入个人色彩太多以避免文意曲解）导致可能看着有些拗口。
   实际上这个异常就是文案上的含义：
   1. 多线程时，发生并发修改时，这个异常会抛出；
   2. 单线程时，在遍历过程中修改了集合，这个异常也会抛出；
   3. 我们对这个异常是否可以正确抛出是不做严格保证的。因为这种机制是谁都不可能严格地去说，对，这里一定会抛出这个异常。所以，这里是非常不建议我们的程序依赖这个fail-fast机制来编写程序。它最佳的用处也就是检测bug，而不是依此来进行复杂业务处理。

---

ConcurrentModificationException类信息：

public class ConcurrentModificationException extends RuntimeException

   我们可以清楚的看到，ConcurrentModificationException 一个是继承自RuntimeException类的异常类。

---

ConcurrentModificationException静态变量信息：

/* 序列化版本编号 */
private static final long serialVersionUID = -3666751008965953603L;

   我们来看ConcurrentModificationException的静态变量信息。
   这里的静态变量信息唯独就是生成了一个序列化版本编号。这个类的整体集成方式是这样的：ConcurrentModificationException->RuntimeException->Exception->Throwable。而Throwable实现了java.io.Serializable接口。所以这里有一个序列化版本编号也不足为奇。

---

ConcurrentModificationException构造函数信息：

/**
 * 构造一个没有详细信息的ConcurrentModificationException异常。
 */
public ConcurrentModificationException() {
}

/**
 * 构造一个指定详细信息的ConcurrentModificationException异常。
 * @param message 与此异常相关的详细信息。
 */
public ConcurrentModificationException(String message) {
    super(message);
}

/**
 * 构造一个带有指定原因和详细信息
 * (cause==null ? null : cause.toString())
 * 的ConcurrentModificationException异常(其中通常包含类和指定
 * 原因的详细信息)。
 * @param  cause 错误原因(该原因将被Throwable.getCause()方法
 * 保存，供以后检索)(允许空值，并指示原因不存在或未知。)
 * @since  1.7
 */
public ConcurrentModificationException(Throwable cause) {
    super(cause);
}

/**
 * 构造一个带有指定原因和详细信息的ConcurrentModificationException异常
 * 请注意，与cause相关的详细信息不会自动合并到此异常的详细信息中。
 * @param  message 详细信息(它被保存起来供以后使用
 * Throwable.getMessage()方法检索)。
 * @param  cause 原因(该原因将被Throwable.getCause()方法保存，供以后检
 * 索)。(允许为空值，并指示原因不存在或未知。)
 * @since 1.7
 */
public ConcurrentModificationException(String message, Throwable cause) {
    super(message, cause);
}

   其实到这里你会发现整个类就已经结束了。对的，这个异常类的所有方法都是其本身的构造方法，是没有其他业务方法的。所以这里一连展示了其4个构造方法，有参的，无参的。同时，这里也一并对其介绍而不需要一个一个的讲解。
   为什么不需要一个一个讲解呢，我们仔细从代码体得知，这些构造方法无不在（除了无参构造器）都在调用其父类的构造方法。而这个父类你都可以追踪到它的祖宗辈儿Throwable类。
   我们整体来看这四个构造方法，其中第二个构造函数是第一个构造函数的扩展体，第四个构造函数是第三个构造函数的扩展体（这两个函数都是从Java1.7才开始有的）。
   那么，其实我们去搜寻现有的Java1.8源码包，也就第一无参构造器和第三有参构造器是被引用的。其中第一无参构造器被引用100次，第三有参构造器仅被引用4次（其中Map接口引用三次，DirectoryIteratorException异常类引用一次）。整个异常类都是在进行错误信息的收集。最主要的关注点其实还是它是如何被触发的，不过它的触发时机已经在上面简述过了，我们只需简单的知道这个类的大体构造就可以了~
   其实到这里我们ConcurrentModificationException到此全部解析完毕了，可能整篇文章显得无所重要，其实不然。因为这整个专题的部分源码分析都会涉及到此异常。这个解析已经是这个类可以提供的全部信息了，其他你想要的解析其实是需要具体到引用其类的源码上的。
   ConcurrentModificationException源码所提供的信息也就到此为止了(ಥ_ಥ)。