23.6 Synchronized Collections and Maps
The primary goal of the Collections Framework is to provide support for efficient computation on collections that can be used in single-threaded applications. In the rest of this chapter we explore the support provided by the Collections Framework and the Concurrency Framework to create thread-safe collections that can be used in multithreaded applications. We start with synchronized collections provided by the java.util package, and explore concurrent collections found in the java.util.concurrent package in the next section (p. 1482).
By a thread-safe collection we mean a collection whose elements can be processed by concurrent threads without ever being in an inconsistent state.
Unmodifiable collections cannot be changed structurally (add and remove operations are prohibited) and their elements cannot be replaced (throw an Unsupported-OperationException), making the unmodifiable collection immutable (§12.2, p. 649). This guarantees that an unmodifiable collection is thread-safe, and multiple reader threads can safely access the elements concurrently as long as it is done via the unmodifiable collection.
// Thread-safe unmodifiable list:
List<String> list = List.of(“Tom”, “Dick”, “Harriet”);
list.add(“Harry”); // UnsupportedOperationException
list.set(0, “Tommy”); // UnsupportedOperationException
list.remove(“Dick”); // UnsupportedOperationException
System.out.println(list.get(0)); // “Tom”
Unmodifiable views of collections are backed by an underlying collection, where changes in the underlying collection are reflected in the view (§15.11, p. 856). Such a view also cannot be modified, and only query methods are passed to the underlying collection. The view can be considered effectively immutable, and thus thread-safe, if the backing collection is effectively immutable, or if the only reference to the backing collection is through the unmodifiable view. An example of such an unmodifiable view is given below:
// Effectively immutable list view:
List<Integer> list = new ArrayList<>();
list.add(2021); list.add(2022);
List<Integer> immutablelist = Collections.unmodifiableList(list);
immutablelist.add(2023); // UnsupportedOperationException
immutablelist.set(0, 2023); // UnsupportedOperationException
immutablelist.remove(2021); // UnsupportedOperationException
System.out.println(immutablelist.get(0)); // 2021
It is worth keeping in mind that a thread-safe collection does not imply that its elements are thread-safe. It might be necessary to employ an appropriate synchronization mechanism on the elements in order to modify them in a thread-safe way.
The java.util.Collections class provides methods to create synchronized collections that are thread-safe. Actually, these collections are synchronized views of collections as they are backed by an underlying collection. The methods provided accept a collection and return a view of this collection in which the getter and setter methods use synchronized blocks to delegate operations to the underlying collection—that is, the methods provide a synchronized wrapper around the underlying collection. A single intrinsic lock on the synchronized collection implements mutual exclusion of operations, but this can potentially become a point of contention among threads. Synchronized collections also incur the performance penalty associated with intrinsic locking. Other thread-safe solutions explored in this chapter should be considered before settling on using a synchronized view to make a collection thread-safe.
static <E> Collection<E> synchronizedCollection(Collection<E> c)
static <E> List<E> synchronizedList(List<E> list)
static <E> Set<E> synchronizedSet(Set<E> set)
static <E> SortedSet<E> synchronizedSortedSet(SortedSet<E> set)
static <E> NavigableSet<E> synchronizedNavigableSet(NavigableSet<E> set)
Return a synchronized (thread-safe) view collection that has the same type as the specified backing collection. It is imperative that any access to the backing collection is accomplished through the returned collection (or its views) to guarantee serial access.
Analogous to an unmodifiable view collection (§15.11, p. 856), the synchronized collection returned by the synchronizedCollection() method does not delegate the equals() and the hashCode() methods to the backing collection. Instead, the returned collection uses the corresponding methods inherited from the Object class. This is to safeguard the contract of these methods when the backing collection is a set or a list. However, the synchronized collections returned by the other methods above do not exhibit this behavior.
static <K,V> Map<K,V> synchronizedMap(Map<K,V> map)
static <K,V> SortedMap<K,V> synchronizedSortedMap(SortedMap<K,V> map)
static <K,V> NavigableMap<K,V>
synchronizedNavigableMap(NavigableMap<K,V> map)
Return a synchronized (thread-safe) view map that has the same type as the backing map that is specified. It is imperative that any access to the backing map is accomplished through the synchronized map (e.g., its key, entry, or values views) to guarantee thread-safe serial access.
We use the synchronized list as an example in this section. For using the other synchronized collections and maps, familiarity with their unsafe counterparts will go a long way. For the most part, the synchronized collections provide mutually exclusive operations corresponding to the operations on their unsafe counterparts.