在 Scala 中，集合是处理数据的核心工具，而 Set 作为一种不允许重复元素的集合类型，其 “可变” 与 “不可变” 的区分的区分，直接影响代码的逻辑设计、性能优化甚至并发安全性。本文将通过代码示例，深入浅出地解释两者的本质差异、使用场景及核心特性。
一、先明确核心前提：Scala 集合
Scala 语言的设计理念之一是 “偏好不可变”—— 默认情况下，我们使用的集合都是不可变的。这背后的核心原因是：不可变集合天然具备线程安全、逻辑可预测、减少 bug 等优势，尤其适合并发编程和函数式编程场景；而可变集合则允许直接修改数据，更适合对性能要求极高、需要频繁更新数据的场景。
简单来说：
- 不可变集合：创建后，其内部元素无法被添加、删除或修改，任何 “更新” 操作都会生成一个新的集合；
- 可变集合：创建后，可直接对原集合进行添加、删除等操作，集合本身的引用不变，内部数据实时变更。
二、可变 Set 的 “直接操作” 特性
我们先看代码中可变 Set 的实现：
// 定义可变 Set
var set1 = scala.collection.mutable.Set("apple","grape","apple","pear")
// 向集合添加元素
set1 += "banana"
// 输出结果
println(set1)
1. 关键细节
- 显式声明 “可变” ：通过
scala.collection.mutable.Set明确指定集合类型为可变。mutable是 “可变” 的英文直译，这部分包路径是区分可变与不可变集合的核心标识 var关键字的作用：这里用var声明变量set1，表示set1的引用可以被重新赋值，但在可变集合的使用中，我们更关注的是 “集合本身可修改”—— 即使set1是var，真正实现数据变更的是集合的可变特性，而非变量的可赋值性- 去重特性：
Set的核心规则是 “不允许重复元素”，因此即使初始化时传入了两个"apple"，最终集合中只会保留一个 +=操作的本质：set1 += "banana"是对原集合的 “直接修改”—— 没有创建新的集合对象，而是在set1指向的原集合中添加了"banana"元素
2. 输出结果与逻辑
由于 Set 是无序集合，输出结果可能是 Set(apple, grape, pear, banana)元素顺序不固定，无重复。这个结果证明：我们确实对原集合进行了修改，且 set1 始终指向同一个集合对象。
三、不可变 Set 的 “创建新集合” 特性
再看不可变 Set 的实现：
// 定义不可变 Set
val course = scala.collection.immutable.Set("apple","banana")
// 报错：course += "xxx"
// “更新”集合：生成新集合
var newCourse = course + "pear"
// 输出新集合
println(newCourse)
1. 关键细节
- 默认的不可变特性：
scala.collection.immutable.Set是 Scala 的默认Set类型，不可变集合的核心约束是 “原集合不可修改” val关键字的适配：用val声明变量course，表示course的引用不可被重新赋值 —— 这与不可变集合的特性天然匹配：既然集合本身不能修改，变量引用也无需变更- 为什么
course += "xxx"会报错？ ：+=操作对不可变集合来说是非法的。因为不可变集合不允许直接修改原数据，编译器会阻止这种 “试图修改原集合” 的操作 - “更新” 的正确方式：
course + "pear"并非修改原集合，而是创建一个新的不可变Set—— 新集合包含原集合course的所有元素，再新增"pear"元素。我们用newCourse变量接收这个新集合，原集合course的内容依然保持不变
2. 输出结果与逻辑
输出结果为 Set(apple, banana, pear)。这里的关键是：course 仍然是 Set(apple, banana)，newCourse 是一个全新的集合 —— 不可变集合的 “更新” 本质是 创建新实例。
四、核心差异对比：一张表看懂可变与不可变 Set
| 特性 | 可变 Set（mutable.Set） | 不可变 Set（immutable.Set） |
|---|---|---|
| 包路径 | scala.collection.mutable.Set | scala.collection.immutable.Set |
| 数据修改方式 | 直接修改原集合（添加、删除元素） | 生成新集合，原集合保持不变 |
| 常用关键字搭配 | 通常用 var（变量引用可修改，非必需） | 通常用 val（变量引用不可修改，适配特性） |
| 线程安全 | 非线程安全（多线程修改可能导致数据混乱） | 线程安全（无并发修改冲突） |
| 性能 | 频繁更新时性能更高（无新对象创建开销） | 频繁更新时性能较低（需创建新对象） |
| 适用场景 | 单线程、频繁更新数据、追求极致性能 | 并发编程、函数式编程、数据稳定不常变更 |
五、实际中的选择建议
- 优先使用不可变 Set：在没有明确性能瓶颈的情况下，首选不可变
Set。它能减少并发 bug、让代码逻辑更清晰 —— 你无需担心某个地方意外修改了集合数据，尤其适合作为函数参数、全局变量等场景 - 必要时使用可变 Set：当需要频繁添加、删除元素，且性能成为关键指标时，可使用可变
Set。但需注意：单线程环境下使用，或在多线程环境中手动加锁保证安全 - 避免混淆
var/val与集合可变性：var/val控制的是 “变量引用是否可修改”，而mutable/immutable控制的是 “集合本身是否可修改”。例如：var+ 不可变 Set 意味着 “可以让变量指向新的不可变集合”，val+ 可变 Set 意味着 “变量引用不变，但集合内容可修改”
总结
Scala 中 Set 的可变与不可变，本质是数据是否可在原对象上修改的设计选择。不可变集合是 Scala 的默认偏好，契合函数式编程和并发安全的需求；可变集合则是针对性能优化的补充选择
