弱一致性
的定义在
java.util.concurrent软件包文档中给出。为了方便起见,我将引用相关的位。关于弱一致性的迭代器和分离器,文档说:
这并不是说(以及使用“
consistent”一词可能隐含的意思)是,迭代不会导致诸如
IndexOutOfBoundsException或的错误
NoSuchElementException。它也没有说迭代是否会终止!(我相信会的。)从某种意义上说,这种行为确实是一致的,尽管保证还很薄弱。如果在迭代过程中进行了修改,则特别是第三个项目符号不会明确保证迭代会看到哪些元素。
考虑以下示例:
List<String> input = Arrays.asList("a", "b", "c", "d", "e"); List<String> output = new ArrayList<>(); Deque<String> deque = new ConcurrentlinkedDeque<>(input); for (String s : deque) { output.add(s); if (s.equals("c")) { deque.addFirst("XXX"); deque.removeLast(); } }
A
ConcurrentlinkedDeqeue是具有弱一致性迭代语义的集合的示例。该代码对其进行迭代,并将看到的每个元素添加到副本中,但是在迭代过程中,双端队列被修改。
如果您尝试使用a,
linkedList您将得到
ConcurrentModificationException您所期望的。使用
ConcurrentlinkedDeque,输出列表为
[a, b, c, d]
请注意,在删除“ e”之前已添加“ XXX”,因此输出列表仅反映了迭代过程中对输入所做的 一些
修改。由于在这种情况下迭代是从左到右进行的,因此不会看到对当前迭代点左侧进行的修改,而看到对当前迭代点右侧进行的修改也就不足为奇了。当然,并非所有集合都具有如此简单的迭代顺序。
还要注意,输出在任何时间点都不会反映输入的快照。(如果需要快照语义,则需要使用类似的东西
CopyOnWriteArrayList。)唯一的保证是,迭代中看到的元素有时会出现在输入中。这是一个很薄弱的保证!
但是,它比我所说的 不一致 行为要强。考虑下面的代码,该代码使用索引(而不是Iterator对象)在ArrayList上进行迭代:
List<String> input = Arrays.asList("a", "b", "c", "d", "e"); List<String> output = new ArrayList<>(); List<String> arrayList = new ArrayList<>(input); for (int i = 0; i < arrayList.size(); i++) { String s = arrayList.get(i); output.add(s); if (i == 2) { // <<< MODIFY arrayList.add(0, "XXX"); } }
在这种情况下,输出为
[a, b, c, c, d, e]
重复元素“ c”,该元素在输入中仅出现一次。显然这是一个错误。或者,假设标记为MODIFY的行更改为:
if (s.equals("c")) {
在这种情况下,循环将永远不会终止!您还可以轻松地想象一下使用索引样式循环在恰好正确(错误)的时间修改列表将导致的情况
IndexOutOfBoundsException。
因此,您可以看到在修改集合时,有很多事情可能会出错。弱一致性迭代提供了对重复元素以及可能发生的各种错误或无限循环的保证。“弱点”是它们不能保证在迭代过程中准确观察到哪些元素。
最后,请注意, 快速失败 和 弱一致性 是Java
SE规范中定义和使用的特定术语。官方Java文档中未在任何地方使用“故障保护”一词。因此,我建议不要使用“故障安全”来描述任何Java集合的并发修改策略。有人认为“故障安全”与“故障快速”相反,您会在互联网上的各种博客和文章中看到这种情况。坦白说,我认为这是草率的写作,应该避免。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)