> 上一篇我们聊了不可变Map——它O(1)的查找、它的函数式操作，在大数据开发里无处不在。但有个问题：如果你要在一个循环里不断往Map里加key-value对，用不可变Map就会很别扭。这时候你需要的就是可变Map。

很多人学Scala的时候，记住了"不可变优先"这个原则，然后就走到另一个极端——什么都用不可变Map。直到有一天，他写了这么一段代码：

```scala
// 用不可变Map动态统计词频
var wordCount = Map.empty[String, Int]
for (word <- words) {
  val count = wordCount.getOrElse(word, 0)
  wordCount = wordCount + (word -> (count + 1))
}
```

看起来没问题对吧？每次`+`操作返回一个新Map，然后重新赋值给`wordCount`。但当`words`有十万个词的时候，每次`+`操作都要重新构建整个哈希表——这个性能开销，你品，你细品。

这时候你就需要可变Map了。

这篇文章不讲"可变Map是什么"这种入门废话，直接说干货：**为什么不可变Map在动态构建场景下不够用？可变Map的底层是怎么实现的？什么时候你该用可变Map而不是不可变Map？**

![Scala可变Map知识体系](https://developer.qcloudimg.com/http-save/yehe-2482016/6123e5be11c0abb98a471d295e0e3227.jpg)

---

## 先从一个性能问题说起

假设你要写一个词频统计函数：给定一个单词列表，返回每个单词出现的次数。

用不可变Map怎么写？

```scala
// 写法一：用不可变Map
var wordCount = Map.empty[String, Int]
for (word <- words) {
  val count = wordCount.getOrElse(word, 0)
  wordCount = wordCount + (word -> (count + 1))
}
wordCount
```

逻辑很直白：遍历每个单词，如果在Map里就加一，不在就设为1。

但问题在哪？`wordCount + (word -> (count + 1))`是O(n)的——因为不可变Map每次add都要创建一个新的哈希表结构，把旧元素复制过去。十万个单词，就是一百亿次操作。

怎么优化？把`var`换成`val`，把不可变Map换成可变Map：

```scala
// 写法二：用可变Map
import scala.collection.mutable

val wordCount = mutable.Map.empty[String, Int]
for (word <- words) {
  wordCount(word) = wordCount.getOrElse(word, 0) + 1
}
wordCount.toMap  // 最后转成不可变Map输出
```

现在`wordCount(word) = ...`是摊销O(1)的——因为可变Map是原地修改哈希表，不需要复制整个结构。整个函数的复杂度就变成了O(n)。

从几分钟降到几秒，就是这一行改动的差别。

这就是可变Map存在的意义：**在需要动态构建Map的场景下，可变Map的性能远好于不可变Map。**

---

## 可变Map的底层：它就是个可变的哈希表

很多人以为可变Map和不可变Map是两种完全不同的东西。其实它们的底层思路是一样的——都是基于哈希表。

区别在于：

- **不可变Map**：每次add都返回一个新Map，内部会尽量复用旧结构（结构共享），但在动态添加场景下，复用效果有限
- **可变Map**：直接在原哈希表上修改，add/update/remove都是原地操作

```scala
import scala.collection.mutable

// 创建可变HashMap
val map = mutable.HashMap("a" -> 1, "b" -> 2, "c" -> 3)

// add/update：原地修改
map("d") = 4
// HashMap("a" -> 1, "b" -> 2, "c" -> 3, "d" -> 4)

// remove：原地删除
map -= "b"
// HashMap("a" -> 1, "c" -> 3, "d" -> 4)

// get：和不可变Map一样，O(1)
map("a")    // 1
```

看出来了吗？可变Map的API和不可变Map几乎一样——都是`apply`、`-=`、`getOrElse`。区别就是：**可变Map是原地修改，不可变Map是返回新对象。**

这也是为什么Scala的集合体系这么优雅——不管可变还是不可变，它们共享同一套API。你学会了一个，就学会了所有。

---

## 可变Map的几种实现

和不可变Map一样，可变Map也有几种不同的实现，对应不同的场景。

### HashMap：最常用的可变Map

```scala
import scala.collection.mutable.HashMap

val map = HashMap[String, Int]()
map("a") = 1
```

最常用的可变Map，底层就是个可变哈希表。add/update/remove/get都是摊销O(1)。99%的场景用它就够了。

### LinkedHashMap：保持插入顺序

```scala
import scala.collection.mutable.LinkedHashMap

val map = LinkedHashMap[String, Int]()
map("c") = 3
map("a") = 1
map("b") = 2
// LinkedHashMap("c" -> 3, "a" -> 1, "b" -> 2) —— 保持插入顺序
```

有时候你既要通过key快速查找，又要保持key的插入顺序——这时候用LinkedHashMap。它底层是哈希表加链表，既能O(1)查找，又能保持插入顺序。

这个在做配置文件解析、做日志格式处理的时候特别好用——你既要通过配置项名称快速取值，又要保持配置项的原始顺序。

---

## 可变Map vs 不可变Map：怎么选？

这是最常见的困惑。我给一个简单的判断标准：

**你是在"构建"一个Map，还是在"使用"一个Map？**

- 在"构建"——数据是动态收集的，你不知道最终有多少key——用可变Map
- 在"使用"——数据已经有了，你要做查找、做转换、做过滤——用不可变Map

具体到实际场景：

| 场景 | 用什么Map |
|------|----------|
| 循环里动态构建Map（词频统计、分组聚合） | 可变Map |
| 构建后要在多个地方传递 | 不可变Map |
| 需要频繁update/remove | 可变Map |
| 做map/filter转换 | 不可变Map |
| 方法参数传入的Map | 不可变Map（别假设它是可变的） |
| 方法返回的Map | 不可变Map（对外暴露不可变的） |

### 最佳实践：可变构建，不可变输出

这是Scala集合体系的老传统了：**内部用可变Map构建，对外用不可变Map输出。**

```scala
def countWords(words: List[String]): Map[String, Int] = {
  val wordCount = mutable.HashMap[String, Int]()
  for (word <- words) {
    wordCount(word) = wordCount.getOrElse(word, 0) + 1
  }
  wordCount.toMap  // 最后转成不可变Map输出
}
```

这个模式的好处是：

1. **内部高效**：用可变Map构建，性能好
2. **外部安全**：对外暴露不可变Map，调用方拿到的是线程安全的
3. **边界清晰**：可变的东西只在方法内部，不会泄露出去

这和ListBuffer的模式、可变Set的模式是一模一样的——可变收集，不可变输出。

---

## 和Java HashMap对比

Java也有HashMap，也有LinkedHashMap。那Scala的可变Map和Java的HashMap到底差在哪？

### 1. 运算符风格

```java
// Java
Map<String, Integer> map = new HashMap<>();
map.put("a", 1);
map.remove("a");
map.get("a");
```

```scala
// Scala
import scala.collection.mutable
val map = mutable.Map[String, Int]()
map("a") = 1
map -= "a"
map.getOrElse("a", 0)
```

写法上的差别只是表面。真正的差别在这几点：

### 2. getOrElse vs get

Java的`map.get(key)`在key不存在的时候返回`null`——这就是臭名昭著的NPE问题的根源。

Scala的可变Map提供了`getOrElse(key, default)`方法——key不存在的时候直接返回默认值，不需要你判空。

这个设计看起来是小事，但它从根源上消灭了一类bug：`NullPointerException`。

### 3. 默认是不可变的

Java里，你new的HashMap默认就是可变的。你要想要不可变的，得自己用`Collections.unmodifiableMap()`包一层——而且这只是个"视图"，你拿着原始引用还是能改。

Scala里，默认的`Map`就是不可变的。你要可变的，得显式import`mutable.Map`。

这个设计哲学的差别和List、Set是一样的：**把可变性上升到类型层面，编译器帮你检查。**

---

## 几个真正影响性能的细节

### 1. toMap是O(n)，不是O(1)

和可变Set一样，可变Map的toMap不是零拷贝的——它需要把可变哈希表复制成一个不可变Map。所以如果你最后不需要转成不可变Map，那就别转。

但大多数情况下，这个复制的开销是值得的——因为你对外暴露不可变Map，调用方用起来更安全。

### 2. 可变Map不是线程安全的

这个不用多说了，可变集合都不是线程安全的。如果你在多线程环境下需要共享Map，要么用不可变Map，要么自己加锁，要么用并发集合（ConcurrentHashMap）。

### 3. 大数据量下，Map的内存开销比List大

Map要维护哈希表，内存开销比List大。如果你的数据量特别大——比如几百万个key——那Map的内存占用可能是List的好几倍。这时候你要权衡：你要O(1)的查找，还是要省内存？

---

## 写在最后

我写这篇文章的时候，特意没罗列可变Map有多少个方法——因为那些东西官方文档都有，查一下就行。

真正值得花时间理解的是：**为什么需要可变Map？**

不是因为"它就是Java HashMap的Scala版"，而是因为在动态构建数据的场景下，不可变Map的性能不够好。你要在循环里不断往Map里加key-value对，用不可变Map就是O(n²)的灾难，用可变Map就是O(n)的高效。

但可变Map也不是万能的。它只适合"构建"场景——你在一个方法内部，动态构建一个Map，最后输出一个不可变Map。一旦数据构建完了，你就该把它转成不可变Map，在系统里安全地传递。

这就是Scala集合体系的核心哲学：**可变用于构建，不可变用于传递。**

理解了这个，你就理解了Scala集合设计的精髓。你不会再纠结"为什么不直接用Java的HashMap"——因为你知道，这不是哪个更好的问题，而是设计哲学的区别。

Java的集合是"命令式"的：你有一个可变容器，你往里面加东西、删东西，容器一直在变。

Scala的集合是"函数式"的：数据是不可变的，你操作数据的时候会生成新的数据。而在这个过程中，如果你真的需要一个可变的临时容器，Scala也给你准备好了——就是可变Map。

它不是"更好的HashMap"，它是函数式编程世界里，那个让你可以安全地"作弊"的小窗口。平时你守规矩，用不可变Map；但当你真的需要动态构建数据的时候，可变Map给你提供了一个高效的临时工作台。

上一篇我们聊了不可变Map——它O(1)的查找、它的函数式操作，在大数据开发里无处不在。但有个问题：如果你要在一个循环里不断往Map里加key-value对，用不可变Map就会很别扭。这时候你需要的就是可变Map。

深入理解Scala可变Map：动态构建场景下的性能与设计权衡

编程语言

大数据

深入解析Scala可变Map与不可变Map的性能差异及选型策略。通过词频统计案例，对比O(1)原地修改与O(n²)复制重建的性能差距，详解HashMap、LinkedHashMap实现原理，总结"可变构建、不可变输出"的最佳实践与线程安全注意事项。

代码解释

编译器

容器

Java

2026上云采购 | AI焕新·智启新局

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

深入理解Scala可变Map：动态构建场景下的性能与设计权衡-腾讯云开发者社区-腾讯云

深入理解Scala可变Map：动态构建场景下的性能与设计权衡

深入理解Scala可变Map：动态构建场景下的性能与设计权衡

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐