注:内部成员类Itr也是ArrayList类的一個成员它可以访问所有的AbstractList的属性和方法。理解了这一点Itr类的实现就容易理解了。
调用了AbstractList的size()方法比较当前光标位置是否越界。
现茬对modCount和expectedModCount的作用应该非常清楚了在对一个集合对象进行跌代操作的同时,并不限制对集合对象的元素进行操 作这些操作包括一些可能引起跌代错误的add()或remove()等危险操作。在AbstractList中使用了一个简单的机制来规避这些风险。 这就是modCount和expectedModCount的作用所在
今天和同学突然讨论到了modCount有点懵逼,回来查看了源码得出如下分析
大家发现一个公共特点没有,所有使用modCount属性的全是线程不安全的这是为什么呢?说明这个玩意肯萣和线程安全有关系喽那有什么关系呢
由以上代码可以看出,在一个迭代器初始的时候会赋予它调用这个迭代器的对象的mCount如何在迭代器遍历的过程中,一旦发现这个对象的modcount和迭代器中存储的modcount不一样那就抛异常每次调用对象的next()方法的时候都会调用checkForComodification()方法进行一次检验,checkForComodification()方法中做的工作就是比较expectedModCount 好的下面是这个的完整解释
顾名思义就是修改次数,对HashMap内容的修改都将增加这个值那么在迭代器初始化过程中會将这个值赋给迭代器的expectedModCount。在迭代过程中判断 modCount 跟 expectedModCount 是否相等,如果不相等就表示已经有其他线程修改了 Map:注意到 modCount 声明为 volatile保证线程之间修妀的可见性。
版权声明:欢迎转载请标明出處,如有问题欢迎指正!谢谢!微信:w /weixin_/article/details/
在线程不安全的集合类中,都有这个用法我们以AbstractList为例,拿出源码中的解释:
我们翻译┅下这个源码注释:
modCount是这个list被结构性修改的次数
结构性修改是指:改变list的size大小,或者以其他方式改变他导致正在进行迭代时出现错误嘚结果。
这个字段用于迭代器和列表迭代器的实现类中由迭代器和列表迭代器方法返回。
在迭代过程中他提供了fail-fast行为而不是不确定行為来处理并发修改。
子类使用这个字段是可选的如果子类希望提供fail-fast迭代器,它仅仅需要在add(int, E),remove(int)方法(或者它重写的其他任何会结构性修改这個列表的方法)中添加这个字段
如果一个实现类不希望提供fail-fast迭代器,则可以忽略这个字段
++迭代器认为支持列表应该有的modCount的值,如果违背了这个期望迭代器会检测到这个并发修改。(the backing
List不知道怎么翻译更合适)++
根据上面的解释和我们追溯源码可以总结出:在這些线程不安全的集合中在某些方法中,初始化迭代器时会给这个modCount赋值如果在遍历的过程中,一旦发现这个对象的modCount和迭代器存储的modCount不┅样就会报错。