A hodgepodge--fast-fail analysis of iterator in Java

A hodgepodge of basics--catalogue

Javais Iterator very convenient for all data sources to provide a uniform data read (delete) interface, but novice usually in use when the following error ConcurrentModificationException is easy to report, because the use of iterators when the underlying data is modified, the most common to the data source is not a thread-safe class, such as HashMap & ArrayList .

Why should there be a case of fast-fail

An example of a novice who is prone to make mistakes:

String[] Stringarray = {"A", "B", "C", "D"}; List<String> strings = arrays.aslist (stringarray); Iterator<String> Iterator =  Strings.iterator ();  while (Iterator.hasnext ()) {      if(Iterator.next (). Equals ("C")) {            strings.remove ("C") );      }}

More commonly, in the case of foreach (essentially, it is called iterator, the original strings) statement is manipulated:

 for (String s:strings) {      if(S.equals ("C")) {            strings.remove ("C");}  } 

Cause

JavaThere are two types of collection classes (data sources) in a thread-safe location java.util.concurrent under a named directory, such as CopyOnWriteArrayList thread insecurity: Located in a java.util directory, such as ArrayList,HashMap . The so-called thread safety is in the multi-threaded environment, this class can also show consistent with the behavior of the results, whether genteel ... Google it yourself.

So why do we have to be there if we can safely assemble substitutes on the wire ArrayList ? Because thread-safe classes often require a variety of means to maintain synchronization of data access, it is generally inefficient. The use of non-thread-safe collection classes has a significant speed advantage if the user is aware that there is no concurrent scenario for their own usage scenarios.

If the developer is not aware of the use of the non-thread-safe collection class in a concurrent scenario, such as thread A obtained ArrayList iterator , and then thread B through the call to ArrayList.add() modify the ArrayList data, it is possible to throw ConcurrentModificationException , note that this is It's possible . So why do the above examples also report this error? There is no concurrency, hug one eye source bar.

Iterator Source Code Analysis

The implementation in the collection class fast-fail is similar, let's take the simplest ArrayList example.
ArrayListwill hold a variable, declared as:
protected transient int modCount = 0;The record is ArrayList how many times we have changed, such as when we call to add(),remove() change the data modCount++ .

We ArrayList.iterator() return by the one that implements the Iterator interface ArrayListIterator :

Private classArraylistiteratorImplementsIterator<e> {    //omit part of the code ....//the number of changes that are assigned to Expectedmodcount directly to ArrayList when initializing    Private intExpectedmodcount =Modcount; @SuppressWarnings ("Unchecked") PublicE Next () {...... ArrayList<E> ourlist = ArrayList. This; //simply compare the values of Arraylist.modcount at the current iterator initialization//is the same as the current value, if it is not equal, it is considered that after acquiring the present iterator//different positions (possibly other threads) modified the ArrayList, throwing the exception directly        if(Ourlist.modcount! =Expectedmodcount) {            Throw Newconcurrentmodificationexception (); }          ............    }}

The principle is very simple, the construction Iterator will be the current ArrayList modCount save, each subsequent time next() , the ArrayList value of the judge modCount whether there is a change, if there is, in the process there is code to change the data (previously mentioned, only the call add() remove() will be modified modCountvalues).
This also shows why in the example we are not concurrent scenarios also error, because we call ArrayList.remove() when modCount the value changed.

But how much does this thing mean? It seems to me that it is a little superfluous suspicion. Because in a real concurrency scenario, this fast-fail mechanism does not really even find additional threads to access and modify ArrayList the data in. The reasons are as follows:

1. Look at modCount the definition again protected transient int modCount = 0; . You are not mistaken, it is a normal variable, then in the concurrency scenario due to the invisible of the shared object, it is possible that other threads are modified ArrayList modCount , and iterator the thread that is not reading this update. HashMapbefore 1.6 was really used volatile to decorate modCount to ensure that each thread directly to modCount the visibility, but in 1.7 to remove the decoration, and think this is a bug-->java7 remove volatitle, sad ah ... The reason for this is that JDK developers think it's wasteful to use it for this crap volatitle .

2. Even if it is used, bob it? volatitle Nono, for the simplest example, thread a acquires a collection class Iterator , thread B calls the collection class add() , and add() when it is not yet executed, modCount++ thread A gets execution and executes the end. In this scenario, the execution results are not deterministic. For ArrayList The Iterator case, it is possible to report an array of exceptions that are out of bounds ...

Summarize

fast-failIt's the JDK. To prompt the developer to use a non-thread-safe class in a concurrent scenario, throw an exception to find the problem in the code early. However, as mentioned earlier in this article, this mechanism is not absolutely correct to give hints, and the old JDK version in order to better support the mechanism also paid a certain cost of efficiency.

fast-failThe only value that exists may be to create some confusion for the novice, to give him the impetus to explore deeply ... Hey

Add:

Many online sources say that Iterator data cannot be modified at the time of use, and this is not entirely accurate. Even the support fast-fail Iterator itself is provided remove() to delete the currently traversed element, for example: ArrayListIterator中的remove() The chestnut above is changed to the following:

 while (Iterator.hasnext ()) {      if(Iterator.next (). Equals ("C")) {            iterator.remove ("C") );      }}

La La la

A hodgepodge--fast-fail analysis of iterator in Java