集合的modCount字段和Fail-Fast,Fail-Safe机制解释

发现前面博客遗失了一篇ArrayList源码解析的文章,这里就不打算重写了,但是其中关于Fail-Fast机制的知识还是有必要记录一下。

Fail-Fast机制

集合类数据类型都有一个迭代器用于遍历集合,这样的设计是为了能使用共同的方式迭代集合,而不依赖于集合的类型的具体实现,比如无论哪种集合类型,都能使用foreach迭代。
但是在这个迭代过程中,我们需要防止通过原集合的提供的api对集合进行修改。因为这可能导致迭代结果不符合预期,或者是出现角标越界等问题。

  • 不符合预期的情况:在迭代过程中,往迭代的位置前插入元素,那么这个元素不会被迭代到。如果修改已经迭代过的元素,那么迭代结果也和当前集合不一致。
  • 角标越界的情况:迭代过程中,删除元素,迭代器游标可能超过了集合的长度。

所以在集合的基类中就定义了modCount字段,每当调用会对集合数据结构产生变化的方法时,modCount++。
而迭代器中则定义了expectCount字段,在迭代器创建时,expectCount赋值为modCount,当迭代时出现expectCount不能与modCount时就会抛出ConcurrentModifiedException,这就是所谓的Fail-Fast机制:在迭代过程中可能出现错误的时候,提前抛出并发修改异常,中断迭代操作

当然,自己实现集合的子类也可以忽略这个字段,不需要Fail-Fast机制。在modCount字段中上面有这么一段文档注释:

If an implementation does not wish to provide fail-fast iterators, this field may be ignored.

容易误解的地方

我看有篇博文说modCount是被volatile修饰的,然后这个小伙伴就将Fail-Fast机制和多线程一起巴拉巴拉的说了一堆……我翻完了jdk各个版本的源码都没发现这个修饰,估计是将transition误以为volatile了。但其实即使是volatile也无法保证modCount线程安全,因为modCount++并不是一个原子性操作……

有的人觉得Fail-Fast机制和多线程有关、modCount是为了多线程设计的,这是很严重的错误的理解。
并不是多线程才会抛出并发修改异常的,而且这个机制也不是针对多线程设计的,modCount对多线程的意义不大,因为主线程中modCount++后,子线程读取到的可能还是自增前的数值,所以多线程情况下反而可能不抛出ConcurrentModifiedException了,导致Fail-Fast机制失效。

Fail-Safe

在线程安全的集合中,迭代器是拷贝集合的副本进行迭代的,所以即使在迭代过程中修改原集合,也不会出现角标越界的情况。但相对的,会出现不符合预期的情况,此时迭代结果和原集合内容已经不一致。
所以这就是Fail-Safe命名的由来,安全的错误。

©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值