When is CopyOnWriteArraySet useful to achieve thread-safe HashSet?

Question

In Java, there is thread-safe version HashMap named ConcurrentHashMap and thread-safe version TreeMap named ConcurrentSkipListMap, but there is no Concurr

Answer 1

Copy-on-write structures are functionally immutable.

Java at one point had a very poor story for providing immutable views on writeable structures such as sets. For example, if you had a set member, and you returned it publicly, the caller could just turn around and edit it, and therefore be editing your object's internal state! But what else can you do, copy the entire thing before returning from any public function? That would be pointlessly slow.

This was the story earlier in Java history. They relied almost exclusively on immutable objects (string is an example). Collections were an exception to this pattern, and were therefore problematic from an encapsulation perspective. When CopyOnWriteArraySet was added, unmodifiableCollection and unmodifiableSet did not yet exist (although unmodifiableCollection has largely solved the problem, I still find it a more cumbersome solution than what other languages offer, especially when using custom data structures). So this explains probably the largest motivation for creating CopyOnWriteArraySet in the first place. You could return a CopyOnWriteArraySet without fear of somebody else modifying your object's internal state, and without wasting time making unnecessary copies.

Copy-On-Write was a fad several years ago, but it is a notoriously inefficient idea for multi-threaded programming and is less efficient than other models. From the documentation you've posted, they've sped up iterating over it by creating thread-local snapshots, which means they are spending memory to compensate. So it's a perfectly okay class to use as long as your data is small... because the memory snapshots won't add up to much wasted memory.