Не совсем.В моем понимании отказоустойчивые итераторы работают с моментальными снимками данных и гарантируют согласованное представление представленной коллекции в тот момент, когда итератор был создан.(см. в этом блоге для более детальной обработки этого вопроса).Это свойство гарантируется итераторами CopyOnWriteArrayList.Его итераторы не поддерживают операции модификации коллекции, и его javadoc дополнительно разъясняет их поведение:
Этот массив никогда не изменяется в течение времени жизни итератора, поэтому вмешательство невозможно, и итератор гарантированно не генерирует исключение ConcurrentModificationException.Итератор не будет отражать добавления, удаления или изменения в списке с момента его создания.Операции изменения элементов на самих итераторах (удаление, установка и добавление) не поддерживаются.Эти методы генерируют исключение UnsupportedOperationException.
ОБНОВЛЕНИЕ:
Когда речь идет об отказоустойчивости и отказоустойчивости, важно отделить «отказ».В случае итератора существуют разные случаи и опасности.Что касается связанной статьи, я бы сказал, что там автор реализует отказоустойчивые и отказоустойчивые итерации , в первую очередь путем реализации итераторов.
Ошибка в этом случае может быть определена как одновременная модификация повторного набора.Когда коллекция модифицируется, то подходом к отказоустойчивости будет остановка итерации и информирование вызывающего абонента об изменившихся условиях (через CME или каким-либо другим способом).
Имея дело с одним и тем же сценарием использования и опасностью, мы можем двигаться дальше и думать о безаварийной итерации.Свойство отказоустойчивости означает, что итерация должна соответствовать своему контракту настолько долго, насколько это возможно (и авторы COWAS успешно копируют базовые данные).