One: fail-fast
When traversing a collection object with an iterator, if the content of the collection object is modified (added, deleted, modified) during the traversal process, a Concurrent Modification Exception will be thrown.
Principle: The iterator directly accesses the contents of the collection when traversing, and uses a modCount variable during the traversal. If the content of the collection changes while it is being traversed, the value of modCount will change. Whenever the iterator uses hashNext()/next() to traverse the next element, it will check whether the modCount variable is the expectedmodCount value, and if so, return the traversal; otherwise, throw an exception and terminate the traversal.
Note: The throw condition of this exception is that modCount is detected! =expectedmodCount This condition. If the modified modCount value happens to be set to the expectedmodCount value when the collection changes, the exception will not be thrown. Therefore, the programming of concurrent operations cannot depend on whether this exception is thrown or not. This exception is only recommended for detecting concurrent modification bugs.
Scenario: The collection classes in the java.util package are all fail-fast and cannot be concurrently modified (modified during iteration) under multiple threads.
Two: fail-safe
A collection container that adopts a failsafe mechanism does not directly access the collection content during traversal, but first copies the original collection content and traverses the copied collection.
Principle: Since the copy of the original collection is traversed during iteration, the modifications made to the original collection during the traversal process cannot be detected by the iterator, so the Concurrent Modification Exception will not be triggered.
Disadvantages: The advantage of copy-based content is to avoid Concurrent Modification Exception, but in the same way, the iterator cannot access the modified content, that is, the iterator traverses the copy of the collection obtained at the moment of traversal, and during the traversal, the original Modifications that occur to the collection are not known to the iterator.
Scenario: The containers under the java.util.concurrent package are all safe to fail, and can be used and modified concurrently under multiple threads.
In JDK Collection we often see something like this:
For example, ArrayList:
Note that the fail-fast behavior of iterators cannot be guaranteed, because in general it is impossible to make any hard guarantees about whether out-of-sync concurrent modifications will occur. Fail-fast iterators will do their best to throw ConcurrentModificationException. Therefore, it would be wrong to write a program that relies on this exception in order to improve the correctness of such iterators: the fail-fast behavior of iterators should only be used to detect bugs.
HashMap中：
Note that the fail-fast behavior of iterators is not guaranteed, and in general it is impossible to make any firm guarantees in the presence of unsynchronized concurrent modifications. Fail-fast iterators do their best to throw ConcurrentModificationException. Therefore, it is wrong to write programs that depend on this exception, and it is right: the fail-fast behavior of iterators should only be used to detect program errors.
"Fail fast" is mentioned repeatedly in these two passages. So what is a "fail fast" mechanism?
"Fail fast", also known as fail-fast, is an error detection mechanism for Java collections. When multiple threads perform structural changes to the collection, a fail-fast mechanism may occur. Remember that it is possible, not certain. For example: Suppose there are two threads (thread 1, thread 2), thread 1 traverses the elements in set A through Iterator, and at some point thread 2 modifies the structure of set A (it is a modification of the structure, not a simple Modify the content of the collection element), then the program will throw a ConcurrentModificationException exception at this time, resulting in a fail-fast mechanism.
References:
http://www.cnblogs.com/ygj0930/p/6543350.html