I just thought I'd mention that I've found Java's java.util.concurrent classes fairly well thought out, just for example ConcurrentHashMap or CopyOnWriteArrayList, perhaps that could serve as a bit of inspiration...

Trouble is, when it comes to iterators, the designers of ConcurrentHashMap seem to have abdicated their responsibility. The docs say:

The view's iterator is a "weakly consistent" iterator that will never throw ConcurrentModificationException, and guarantees to traverse elements as they existed upon construction of the iterator, and may (but is not guaranteed to) reflect any modifications subsequent to construction.

And I can find no mention at all of what happens if another thread resizes the thing when the iterator is half way through. They even proudly announce:"and there is not any support for locking the entire table in a way that prevents all access."

I translate that as: this is a hard problem, so we didn't make any attempt to handle it in a clean way; nor to detect possible inconsistencies; nor even provide a way for you to detect them; nor even a way for you to prevent them.

But oh, they did think to provide a method to look up keys from their values:containsValue(Object value) Returns true if this map maps one or more keys to the specified value. Note: This method requires a full internal traversal of the hash table, and so is much slower than method containsKey..

A bit like a gun maker providing a tool for looking down the barrel to see if it is loaded; and attaching a note: Be careful!