ConcurrentHashMap.keySet（）。removeAll（）性能问题

Question

I am reading about ConcurrentHashMap and checked the removeAll() implementation of its key set. In the current implementation JAVA is iterating the whole key set data structure, even if the given collection contains only one or no elements.

Actual implementation

public final boolean removeAll(Collection<?> c) { 
        if (c == null) throw new NullPointerException(); 
        boolean modified = false; 
        for (Iterator<E> it = iterator(); it.hasNext();) { 
            if (c.contains(it.next())) { 
                it.remove(); 
                modified = true; 
            } 
        } 
        return modified; 
    } 

Could some one tell me if this is intended by JAVA developers or i am just over thinking about it

Answer 1

Posting expected implementation , but to be very frank i am not actual author of the code below, found this on some coding blog while reading about concurrent hashmap so would like to share with every one else.

public boolean removeAll(Collection<?> c) { 
        boolean modified = false; 

        if (size() > c.size()) { 
            for (Iterator<?> i = c.iterator(); i.hasNext(); ) 
                modified |= remove(i.next()); 
        } else { 
            for (Iterator<?> i = iterator(); i.hasNext(); ) { 
                if (c.contains(i.next())) { 
                    i.remove(); 
                    modified = true; 
                } 
            } 
        } 
        return modified; 
    }

Answer 2

The KeySet in a regular Map (like HashMap ) implements AbstractSet . For OpenJDK 8, the source code shows this as the removeAll method:

public boolean removeAll(Collection<?> c) {
    Objects.requireNonNull(c);
    boolean modified = false;

    if (size() > c.size()) {
        for (Iterator<?> i = c.iterator(); i.hasNext(); )
            modified |= remove(i.next());
    } else {
        for (Iterator<?> i = iterator(); i.hasNext(); ) {
            if (c.contains(i.next())) {
                i.remove();
                modified = true;
            }
        }
    }
    return modified;
}

As you can see, there's a check for which collection has the most entries. If the Set itself has a larger size, iteration is done over the given collection argument. Otherwise it's done over the entries of the Set itself. So if the collection you pass in has no entries, zero actual loop executions are performed. Same if the Set itself has no entries.

For ConcurrentHashMap , however, the keySet() method returns an instance of internal class KeySetView , which implements another internal class CollectionView . The removeAll implementation of that one does conform to the code you posted, which always iterates over the KeySetView entries themselves, not the given collection.

The reason for this is likely that the Iterator s returned by the views (key set or entry set) allow concurrent access by reflecting the values that are present at the time the iterator is requested. From the Javadoc of ConcurrentHashMap :

Similarly, Iterators and Enumerations return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration. They do not throw ConcurrentModificationException. However, iterators are designed to be used by only one thread at a time.

So the method forces the use of the key view's Iterator itself to take care of consistency across concurrent actions on the view or map.

Note however that the above implementation for AbstractSet isn't necessarily optimal either. If the collection c you supply as an argument has a larger size than the set, c.contains(element) is called for every element in the set, but depending on the collection's type that contains method might not be nearly as efficient. For an ArrayList , for example, contains runs in linear time, while presence of the object in a set would be detected in constant time.

Answer 3

Collection vs. Set

The implementation in question comes from AbstractCollection class, while the implementation in solution comes from AbstractSet which iherits from AbstractCollection .

The performance improvement stems from the fact that in Collection you cannot guarantee that the elements are unique, therefore the size() call is not enough to optimise the removal. In Set however uniqueness is guaranteed, therefore additional assumptions and performance improvements can be made, like iterating through a smaller set when establishing which elements to remove.

Highly Specialised Map and its sets

The story however is entirely different in both key and value sets of ConcurrentHashMap . This is because ConcurrentHashMap is a highly specialised Map with many assumptions and improvements for concurrency made. This makes any such generic performance improvements like in Set.removeAll() not that valid anymore (in the light of the actual implementation).

ConcurrentHashMap iterator is weakly consistent and does a lot of magic behind the scenes. Perhaps removeAll on key set is the price one pays for all other performance (from concurrent access point of view) gains.

Just follow iterator().remove() on ConcurrentHashMap down the rabbit hole of ConcurrentHashMap.replaceNode() , to see how much logic is hinding in the source code of replaceNode() to accommodate removal of elements from the iterator.