在实现Iterable接口时,iterator()方法不应该返回集合的克隆吗？

Question

我已经看到很多关于如何实现Iterable接口的例子,其中iterator()方法只返回要迭代的原始集合.但这似乎违背了迭代器的部分目的,因为人们应该能够遍历所述集合,而不必担心收集在你下面的变化.不应该Iterable的iterator()方法总是返回集合的克隆吗？而且,最好是深度克隆？

我知道,这个问题的答案可能部分基于意见,这是意思.但是,我想要的是Iterable接口的原始意图,而不是人们可能会或可能不会决定使用它.

Answer 1

但这似乎违背了迭代器的部分目的,因为人们应该能够遍历所述集合,而不必担心收集在你下面的变化.

这不是迭代器为您提供的保证之一.实际上,ConcurrentModificationException为了提醒程序员在他正在迭代的集合被修改的情况下,创建了一个特殊的异常.

不应该Iterable的iterator()方法总是返回集合的克隆吗？而且,最好是深度克隆？

它绝对可以.然而,这将是非常昂贵的,特别是对于如此基本的操作.想一想:每次你想在一个集合上运行for-each循环时,库就会"哦,等一下,我必须在让你迭代之前克隆这整个1000元素的东西".这将是非常缓慢的,并且当他们认为性能很关键时(这包括很多情况下性能实际上并不重要)时,提示程序员停止使用迭代器.

最重要的是,Java不知道如何克隆你的元素,即使你实现Cloneable(因为Cloneable已经破坏).

当然,您总是可以自己克隆一个集合,并迭代它以更好地隔离并发运行的进程.然而,在这种情况下,程序员需要做出支付这种隔离的决定,这与为他做出这个决定的图书馆不同.