Develop Reference

Can Collection.size() throw ConcurrentModificationException?

As we all know, iterating without synchronization on a collection risks throwing ConcurrentModificationException if another thread happens to concurrently modify the collection.
But what about calling size() on the collection? Does size() involve iteration to count the number of elements in the collection? If that is the case, ConcurrentModificationException may occur (some people report this, for example here, but for me it is not clear that size() was the culprit).
On the other hand, if size() just gets an internal int counter variable, no exception would occur.
Which one is the case?
HUMBLE EDIT: Thanks to the answerers for the precision that this depends on the implementation. I should have mentioned that it is a TreeMap. Can I have this problem with that map? The docs say nothing about TreeMap.size().

The docs don't explicitly state that a ConcurrentModificationException will occur if you invoke Collection#size.
The only real times it's thrown are described in ConcurrentModificationException itself:
This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.
For example, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it. In general, the results of the iteration are undefined under these circumstances. Some Iterator implementations (including those of all the general purpose collection implementations provided by the JRE) may choose to throw this exception if this behavior is detected. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future.
If you're really worried about this sort of thing, then be sure that the concrete implementation of your collection uses an approriate size() method, like ConcurrentLinkedQueue.
Returns the number of elements in this queue. If this queue contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE.
Beware that, unlike in most collections, this method is NOT a constant-time operation. Because of the asynchronous nature of these queues, determining the current number of elements requires an O(n) traversal.
Additionally, if elements are added or removed during execution of this method, the returned result may be inaccurate. Thus, this method is typically not very useful in concurrent applications.

It doesn't matter whether size() will throw ConcurrentModificationException. Almost no collections will throw that exception on size(), but that doesn't make it safe.
When you call size() on a collection that other threads modify, you're reading shared memory. If the collection you're using doesn't offer specific synchronization guarantees and you're not using other synchronization mechanisms, the value you read could be arbitrarily out of date, or it could even correspond to a program state that you would think "hasn't happened yet".

Why Iterators fail fast and are they truly fail fast?

Iterators in Java are fail-fast. If an iterator values change while it is being iterated over, an exception is thrown.
Is this purely to be safe? I am sure that in some cases, it doesn't matter that much if the values change. For example, suppose you were sending non critical alerts to members in an iterator every 10 seconds - why would you care if the contents is changed?
Also, the fail-fast implementation just checks the count. This is flawed in case another thread adds and removes the count will be the same even though the iterator's contents is changed. Would be not be better to use a version number?

The fail-fast behavior is purely to aid debugging. The general rule is that if you modify a collection while iterating over it through some means other than the iterator's members, the behavior of the iterator is no longer predictable. It will throw an exception on a best-effort basis.
As such, any method of tracking that is expensive is a bad idea.

How to Redesigning a method in order for it to work

My code results in an java.util.ConcurrentModificationException error. Here is the following code.
Here is the exact error:
java.util.ConcurrentModificationException
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894)
at java.util.HashMap$KeyIterator.next(HashMap.java:928)
at ca.on.oicr.pinery.lims.gsle.GsleClient.getOrders(GsleClient.java:720)
Line 720 is the second for loop
I posted this question before and was told that "You're adding to orders inside a loop that's looping over the elements of orders, that's what causes the exception. Don't modify a collection you're looping over inside the loop. Likewise with samples". I understand that I to re construct this method and received the following suggestions.
ListIterator<Order> it = orders.listIterator();
while ( it.hasNext() ) {
Order ord = it.next();
if ( ) // some condition
it.remove(); // This wil remove the element that we just got using the next() method
if ( ) // some other condition
it.add(new Order()); // THis inserts the element immediately before the next call to next()
}
Now I am stuck at how to do the adding of the samples and the order when using the iteration method since you would iterate differently though a set, I assume I would use a for loop.
This is the part I am getting confused on how to change in order to not get the java.util.ConcurrentModificationException.
f
So far I have gotten up to here.
java.util.ListIterator<Order> it = orders.listIterator();
while (it.hasNext()) {
it.next().getId();
if (sampleOrderMap.containsKey((it.next().getId())))
{
Set<OrderSample> samples = sampleOrderMap.get(it.next().getId());
}
}`
I just do not know how to put in the rest in a way that I would not get the ConcurrentModificationException

From Java Docs:
ConcurrentModificationException may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.
For example, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it. In general, the results of the iteration are undefined under these circumstances. Some Iterator implementations (including those of all the general purpose collection implementations provided by the JRE) may choose to throw this exception if this behavior is detected. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that this exception does not always indicate that an object has been concurrently modified by a different thread. If a single thread issues a sequence of method invocations that violates the contract of an object, the object may throw this exception. For example, if a thread modifies a collection directly while it is iterating over the collection with a fail-fast iterator, the iterator will throw this exception.
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
To go around this, you can create a temporary collection to add to other than the one you are iterating through.
Then, after you finish iterating, you can use orders.AddAll(tempCollection) to add the new items.

How to simulate ConcurrentModificationException in own class?

I have been reading "Effective Java" Item 60, which is "Favor the use of standard exceptions".
Another general-purpose exception worth knowing about is ConcurrentModificationException. This exception should be thrown if an object that was designed for use by a single thread or with external synchronization detects that it is being concurrently modified.
Normally people face with CME when they try remove from a collection while looping.
But in here I am interested about what would be a concise example on detecting a concurrent modification on self-implemented class object?
I expect it to be something like synchronizing on internal object and related boolean flag, if another thread confronts the flag being false, then throwing exception.
For a simple research I have found in source of ArrayList:
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
but the principle behind how modCount is maintained. I cannot find where it is being decremented.

The modification count is essentially the "revision number" of the collection's state. It is incremented every time there is a structural change to the collection. It is never decremented.
When starting iteration, the iterator remembers the value of the mod count. It then periodically checks that the container's current mod count still equals the remembered value. If it doesn't -- meaning there has been a structural change since iteration began -- a ConcurrentModificationException is thrown.

As for how you would implement this kind of behaviour yourself: Your class depends on some assumptions to work properly, which could be violated if access to an object is not synchronized properly. Try to check those assumptions and throw a CME if you find that they are not true.
In the example of ArrayList, the assumption is that nobody will change the structure of the list while you are iterating over it, so ArrayList keeps track of a modification count that is not supposed to change during an iteration.
However, this checking is only there to make it more likely that a bad access will cause a clean exception instead of weird behaviour - in other words, this exception is just a help to developers and does not need to enforce correctness, because correctness is already compromised when you encounter it.
It is a good idea to offer this kind of help where it does not impact the performance of your class much, but using e.g. synchronization to ensure correct use is probably a bad idea - then you might as well make the class threadsafe to begin with.
This is why the API documentation for ArrayList says:
Note that the fail-fast behavior of an iterator cannot be guaranteed
as it is, generally speaking, impossible to make any hard guarantees
in the presence of unsynchronized concurrent modification. Fail-fast
iterators throw ConcurrentModificationException on a best-effort
basis. Therefore, it would be wrong to write a program that depended
on this exception for its correctness: the fail-fast behavior of
iterators should be used only to detect bugs.

So, the general approach is following: just remember current state of your object and check its state every time when trying to access the object, if state changed, throw your exception!

Concurrent modification error when adding elements to LinkedList

I have an List of LinkedList objects.
List<LinkedList<File1>> backup = new ArrayList<LinkedList<File1>>();
The LinkedList contains some elements. I need to add additional elements dynamically by clicking a button. While doing this, I'm getting a concurrent modification error. I really don't understand why this error is popping up. Here is the code:
private void jButton5ActionPerformed(java.awt.event.ActionEvent evt)
{
// When JOIN button is clicked
int parent_node,dist_node;
// List<File1> temp_list = new ArrayList<File1>();
File1 f_new = new File1();
parent_node = Integer.parseInt(jTextField4.getText());
dist_node = Integer.parseInt(jTextField5.getText());
LinkedList<File1> tmp_bk = backup.get(parent_node);
System.out.println("parent node : " + parent_node);
System.out.println("dist node : " + dist_node);
System.out.println("no of lists : " + backup.size());
f_new.nod = backup.size();
f_new.dist = dist_node;
// temp_list.add(f_new);
tmp_bk.add(f_new);
ListIterator itr = it_bk.get(parent_node);
while(itr.hasNext())
{
File1 f = (File1)itr.next();
System.out.println("NODE : " + f.nod + "DIST : " + f.dist);
}
}

It's probably because you're editing the list, then trying to use the original iterators. The collections API doesn't allow that. You need to create new iterators after editing the list.
For example, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it. In general, the results of the iteration are undefined under these circumstances. Some Iterator implementations (including those of all the general purpose collection implementations provided by the JRE) may choose to throw this exception if this behavior is detected. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that this exception does not always indicate that an object has been concurrently modified by a different thread. If a single thread issues a sequence of method invocations that violates the contract of an object, the object may throw this exception. For example, if a thread modifies a collection directly while it is iterating over the collection with a fail-fast iterator, the iterator will throw this exception.

First, if you really expect people to give their attention to your question, you should do them the favor of asking it clearly and in standard English.
Second, you should provide an indication of exactly where in your code you're getting the ConcurrentModificationError.
Finally, what is it_bk? It just shows up in your code without any explanation. If it is an ArrayList of ListIterators it is certainly possible that its parent_node-th element is in a state where it isn't sure that hasNext() or next() will be safe. I'm guessing you modified the underlying collection with your tmp_bk.add(f_new); and so a pre-existing iterator is worried that its invariants may be violated.
General advice: Don't create and retain iterators (or collections of them). When you want an Iterator, create it, use it, and abandon it.

java.lang.Colletions from JDK 1.5 is not synchronized. In earlier version(jdk 1.4), you wont find this problem.
There are multiple solutions available for these problem and you need to choose one of them wisely as per your use case.
Solution 1: The list can be converted to an array with list.toArray() and iterate on the array. This approach is not recommended if the list is large.
Answer 2: The entire list can be locked while iterating by wrapping your code within a synchronized block. This approach adversely affects scalability of your application if it is highly concurrent.
Answer 3: JDK 1.5 gives you ConcurrentHashMap and CopyOnWriteArrayList classes, which provide much better scalability and the iterator returned by ConcurrentHashMap.iterator() will not throw ConcurrentModificationException while preserving thread-safety.
Answer 4: Remove the current object via the Iterator “it” which has a reference to the underlying collection “myStr”. The Iterator object provides it.remove() method for this purpose.