Is iteration via Collections.synchronizedSet(…).forEach() guaranteed to be thread safe?

Question

As we know, iterating over a concurrent collection is not thread safe by default, so one cannot use:

Set set = Collections.synchronizedSet(new HashSet&l         


        

Answer 1

As you wrote, judging by implementation, forEach() is thread-safe for the collections provided with JDK (see disclaimer below) as it requires monitor of mutex to be acquired to proceed.

Is it also thread safe by specification?

My opinion - no, and here is an explanation. Collections.synchronizedXXX() javadoc, rewritten in short words, says - "all methods are thread-safe except for those used for iterating over it".

My other, although very subjective argument is what yshavit wrote - unless told/read that, consider API/class/whatever not thread-safe.

Now, let's take a closer look at the javadocs. I guess I may state that method forEach() is used to iterate over it, so, following the advice from javadoc, we should consider it not thread-safe, although it is opposite to reality (implementation).

Anyway, I agree with yshavit's statement that the documentation should be updated as this is most likely a documentation, not implementation flaw. But, no one can say for sure except for JDK developers, see concerns below.

The last point I'd like to mention within this discussion - we can assume that custom collection can be wrapped with Collections.synchronizedXXX(), and the implementation of forEach() of this collection can be... can be anything. The collection might perform asynchronous processing of elements within the forEach() method, spawn a thread for each element... it is bounded only by author's imagination, and synchronized(mutex) wrap cannot guarantee thread-safety for such cases. That particular issue might be the reason not to declare forEach() method as thread-safe..

Answer 2

It’s worth to have a look at the documentation of Collections.synchronizedCollection rather than Collections.synchronizedSet() as that documentation has been cleaned up already:

It is imperative that the user manually synchronize on the returned collection when traversing it via Iterator, Spliterator or Stream: …

I think, this makes it pretty clear that there is a distinction between the iteration via an object other than the synchronized Collection itself and using its forEach method. But even with the old wording you can draw the conclusion that there is such a distinction:

It is imperative that the user manually synchronize on the returned set when iterating over it:…

^{(emphasis by me)}

Compare to the documentation for Iterable.forEach:

Performs the given action for each element of the Iterable until all elements have been processed or the action throws an exception.

While it is clear to the developer that there must be an (internal) iteration happening to achieve this, this iteration is an implementation detail. From the given specification’s wording it’s just a (meta-)action for performing an action to each element.

When using that method, the user is not iterating over the elements and hence not responsible for the synchronization mentioned in the Collections.synchronized… documentation.

However, that’s a bit subtle and it’s good that the documentation of synchronizedCollection lists the cases for manual synchronization explicitly and I think the documentation of the other methods should be adapted as well.

Answer 3

As @Holger said, the doc clearly says user must manually synchronize collections returned by Collections.synchronizedXyz() when tranversing it via Iterator:

It is imperative that the user manually synchronize on the returned collection when traversing it via Iterator, Spliterator or Stream:

Collection c = Collections.synchronizedCollection(myCollection);
 ...
synchronized (c) {
    Iterator i = c.iterator(); // Must be in the synchronized block
    while (i.hasNext())
       foo(i.next());
}

I want to explain a bit more about code.

Consider Collections.synchronizedList() method. It returns Collections.SynchronizedList class instance, which extends SynchronizedCollection which defines iterator() as follows:

public Iterator<E> iterator() {
    return c.iterator(); // Must be manually synched by user!
}

Compare this with other methods of SynchronizedCollections, for example:

public String toString() {
    synchronized (mutex) {return c.toString();}
}

Thus SynchronizedList inherits iterator() from SynchronizedCollection, which needs to be synched manually by user.