An interesting question came up on the jsr166 concurrency interest mailing list recently which I felt was worthy of mention. Why is there no ConcurrentHashSet equivalent of the ConcurrentHashMap data structure and how does one achieve the same concurrency and performance characteristics of the latter while maintaining the uniqueness semantics of the former? Currently there exist a few different ways of making a Set concurrent.
- Collections.synchronizedSet(Set<T> s)
However none of these exhibit the lock striped minimal blocking high concurrency characteristics of a ConcurrentHashMap. In actual fact all Set implementations with the exception of EnumSet are little more than wrappers around a second kind of backing implementation. Here are all Set implementations and their corresponding backing implementations in brackets.
- HashSet (HashMap)
- TreeSet (TreeMap)
- LinkedHashSet (LinkedHashMap)
- CopyOnWriteArraySet (CopyOnWriteArrayList)
- ConcurrentSkipListSet (ConcurrentSkipListMap)
- JobStateReasons (HashMap)
Following on from that, for those map implementations for which there aren’t already Set equivalents, the JDK from version 1.6 onwards provides a way for you to create a set with your own choice of backing map implementation. For example one can create a ConcurrentHashSet or a WeakHashSet simply by doing the following.
Collections.newSetFromMap(new ConcurrentHashMap<Object,Boolean>()) Collections.newSetFromMap(new WeakHashMap<Object, Boolean>())
With this knowledge some may opt to use the underlying map implementations directly by themselves and this is a trade off between a solely theoretical performance optimisation and making your choice of collection a semantically correct one.