Two Collection Hierarchies
Scala ships two parallel collection hierarchies: scala.collection.immutable and scala.collection.mutable. When you write an unqualified name like List, Map, Set, or Vector in Scala code, it resolves to the immutable version by default, thanks to aliases defined in Predef and the scala package object. To use the mutable counterpart, you must explicitly import it, typically as scala.collection.mutable.Map or by importing the mutable package and qualifying usage as mutable.Map, mutable.Set, and so on.
Cricket analogy: Scala's two collection hierarchies are like having both a printed final scorecard (immutable) and a live scoring app during the match (mutable) - when a commentator just says "the scorecard" without qualifying it, everyone assumes the official printed version, the way unqualified List defaults to immutable.
Why Immutability by Default
Scala favors immutability by default for several concrete reasons. Immutable collections are inherently safe to share across threads without locks or synchronization, since no thread can ever observe a partially-updated or corrupted state - the collection simply never changes after it's built. This safety doesn't come at the cost of copying everything on every change: persistent immutable data structures use structural sharing, reusing the unchanged parts of the old version rather than deep-copying the whole thing, so producing a "modified" version is efficient. Immutability also supports referential transparency, making code easier to reason about and test since a given collection value can never surprise you by changing underneath a reference you're holding.
Cricket analogy: An immutable scorecard can be photocopied and handed to a hundred commentators simultaneously without anyone worrying it'll change underneath them - exactly why immutable collections are safe to share across threads without locks - while structural sharing means a revised scorecard reuses the untouched overs rather than rewriting the whole innings.
import scala.collection.mutable
// Immutable: prepending conceptually produces a "new" list via structural sharing
val original: List[Int] = List(1, 2, 3)
val extended: List[Int] = 0 :: original // original is untouched
// Mutable: same buffer grows in place
val buffer: mutable.ListBuffer[Int] = mutable.ListBuffer(1, 2, 3)
buffer += 4 // buffer now holds 1, 2, 3, 4 - no new object needed
val asList: List[Int] = buffer.toListWhen to Reach for Mutable Collections
Mutable collections still have their place, particularly for performance-sensitive, tightly scoped code. Building up a sequence with repeated in-place appends using a mutable ArrayBuffer or ListBuffer avoids the allocation overhead of repeatedly creating new immutable collections one element at a time, and once the building is done, converting to an immutable result (toList, toVector) hands back a safe value to the rest of the program. The tradeoff is that mutable collections are not thread-safe by default: concurrent reads and writes from multiple threads can corrupt internal state or produce inconsistent results without explicit synchronization or a concurrent-safe alternative.
Cricket analogy: Building up a long list of ball-by-ball deliveries during a live over is like using a mutable ArrayBuffer - a scorer scribbling each ball directly onto a working sheet is far faster than rewriting the whole scorecard from scratch after every delivery, then converting the finished over to the official immutable record.
Mutable collections such as scala.collection.mutable.HashMap are not thread-safe by default. Concurrent reads and writes from multiple threads can corrupt internal state or produce inconsistent results; use synchronization, java.util.concurrent collections, or immutable collections shared via safe publication instead.
Converting Between Mutable and Immutable
Converting between the two hierarchies is straightforward: toList, toVector, and toBuffer convert a collection to the corresponding target type, and mutable builders like ListBuffer expose a result() method that hands back the finished immutable List. Internally, Scala's collections library uses the Builder pattern to perform these conversions efficiently in a single pass rather than element-by-element rebuilding, which is why calling .toList on a large ListBuffer is fast even though the destination type is completely different from the source.
Cricket analogy: Calling .result() on a ListBuffer after scribbling every ball of an over is like the scorer formally transcribing the working sheet into the official printed scorecard - the moment of conversion where the fast, mutable scratch pad becomes the trusted, immutable record.
ListBuffer append (+=) is O(1) amortized, unlike immutable List's O(n) :+. A common idiom is to accumulate results in a ListBuffer inside a loop, then call .toList once at the end to hand back an immutable List to the rest of your program.
- Scala has two parallel collection hierarchies: scala.collection.immutable and scala.collection.mutable.
- Unqualified names like List, Map, Set, and Vector resolve to the immutable versions by default via Predef.
- Immutable collections are safe to share across threads without synchronization since they can never change after creation.
- Structural sharing lets immutable collections reuse unchanged parts of the old version instead of copying everything.
- Mutable collections like ArrayBuffer and ListBuffer are useful for performance-sensitive, tightly scoped local building of a sequence.
- Mutable collections are not thread-safe by default and require external synchronization for concurrent access.
- Methods like toList, toVector, and toBuffer convert between mutable and immutable representations.
Practice what you learned
1. What do unqualified collection names like List and Map default to in Scala, absent an explicit import?
2. Why are immutable collections generally safe to share across threads without synchronization?
3. What is 'structural sharing' in the context of immutable collections?
4. Which is a typical, appropriate use case for a mutable ListBuffer?
5. What must you do to safely use a mutable HashMap across multiple threads?
Was this page helpful?
You May Also Like
Lists in Scala
Learn how Scala's immutable List works as a singly-linked structure, how to build and traverse it, and the core operations every Scala developer uses daily.
Maps and Sets
Understand Scala's Map and Set collections - how they guarantee unique keys and elements, the difference between immutable and mutable variants, and their core operations.
map, filter, and reduce
Master Scala's core higher-order functions for transforming, selecting, and aggregating collections declaratively instead of writing manual loops.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics