Collections.unmodifiableMap详解：真的不可修改吗？

Collections.unmodifiableMap详解：真的不可修改吗？

在代码审查和面试中，经常会看到这样的写法：

Map<String, String> map = new HashMap<>();

Map<String, String> readOnlyMap =
     Collections.unmodifiableMap(map);

很多人认为：

unmodifiableMap
=
不可修改Map

但实际上：

它并不是真正的不可变Map

本文将从源码角度深入分析：

• unmodifiableMap到底是什么？
• 为什么修改原Map会影响只读Map？
• 它和ImmutableMap有什么区别？
• 实际项目中应该如何使用？

---

目录

• 什么是unmodifiableMap
• 基本使用方式
• 为什么不能直接修改
• 修改原Map会发生什么
• 源码分析
• 设计思想
• 与ImmutableMap区别
• 常见使用场景
• 面试高频问题
• 最佳实践
• 总结

---

一、什么是unmodifiableMap

JDK提供：

Collections.unmodifiableMap()

用于创建：

只读Map视图

方法定义：

public static <K,V> Map<K,V>
unmodifiableMap(Map<? extends K, ? extends V> m)

示例：

Map<String, String> map =
        new HashMap<>();

map.put("name", "Tom");

Map<String, String> readOnlyMap =
        Collections.unmodifiableMap(map);

---

此时：

readOnlyMap

表面上看已经变成：

不可修改Map

---

二、基本使用方式

创建Map：

Map<String, String> map =
        new HashMap<>();

map.put("name", "Tom");

map.put("age", "18");

---

包装：

Map<String, String> readOnlyMap =
        Collections.unmodifiableMap(map);

---

读取：

System.out.println(
        readOnlyMap.get("name")
);

输出：

Tom

正常访问。

---

三、为什么不能直接修改

尝试：

readOnlyMap.put(
        "city",
        "Beijing"
);

运行：

Exception in thread "main"

java.lang.UnsupportedOperationException

---

再试：

readOnlyMap.remove("name");

结果：

UnsupportedOperationException

---

看起来确实：

无法修改

---

很多人到这里就认为：

这是一个真正不可变Map

实际上并不是。

---

四、修改原Map会发生什么

看下面代码：

Map<String, String> map =
        new HashMap<>();

map.put("name", "Tom");

Map<String, String> readOnlyMap =
        Collections.unmodifiableMap(map);

---

此时输出：

System.out.println(readOnlyMap);

结果：

{name=Tom}

---

修改原Map：

map.put("age", "18");

再次输出：

System.out.println(readOnlyMap);

结果：

{name=Tom, age=18}

---

发现：

readOnlyMap也变化了

---

这说明：

unmodifiableMap

并没有复制数据

---

五、内存结构分析

创建：

Map<String, String> map =
        new HashMap<>();

内存：

map

↓

HashMap对象

---

执行：

Collections.unmodifiableMap(map)

后：

map

↓

HashMap对象

↑

readOnlyMap

---

图示：

map
  │
  ▼

HashMap

  ▲
  │

readOnlyMap

---

两个引用：

指向同一个HashMap

---

因此：

修改：

map.put(...)

实际上修改的是：

同一个对象

---

六、源码分析

进入源码：

Collections.unmodifiableMap(map)

返回：

return new UnmodifiableMap<>(m);

---

继续查看：

private final Map<? extends K,
        ? extends V> m;

---

构造方法：

UnmodifiableMap(
        Map<? extends K,
        ? extends V> m) {

    this.m = Objects.requireNonNull(m);
}

---

核心代码：

this.m = m;

---

注意：

这里是：

引用赋值

不是：

new HashMap<>(m)

---

因此：

底层仍然是原Map

---

七、为什么put会抛异常

继续看源码：

public V put(K key, V value) {

    throw new UnsupportedOperationException();
}

---

remove：

public V remove(Object key) {

    throw new UnsupportedOperationException();
}

---

clear：

public void clear() {

    throw new UnsupportedOperationException();
}

---

也就是说：

修改操作全部被禁止

---

但是：

读取操作正常放行

例如：

get()
containsKey()
size()

最终委托给：

m

执行。

---

八、设计思想

为什么JDK这样设计？

原因：

性能

---

如果：

new HashMap<>(m)

每次都复制：

时间复杂度 O(n)

---

而当前实现：

只包装一层

复杂度：

O(1)

---

创建成本极低。

---

九、与ImmutableMap区别

很多人容易混淆：

Collections.unmodifiableMap

和：

Guava ImmutableMap

---

unmodifiableMap

特点：

只读视图

---

修改原Map：

会影响结果

---

示例：

map.put("age", "18");

readOnlyMap同步变化。

---

ImmutableMap

例如：

ImmutableMap<String,String> map =
        ImmutableMap.of(
                "name",
                "Tom"
        );

---

特点：

真正不可变

---

修改原数据：

不会影响

---

创建时：

复制数据

形成独立对象。

---

十、JDK9之后的新选择

JDK9新增：

Map.of()

例如：

Map<String,String> map =
        Map.of(
                "name",
                "Tom",
                "age",
                "18"
        );

---

尝试：

map.put("city","BJ");

直接报错：

UnsupportedOperationException

---

并且：

是真正不可变

---

推荐：

JDK9+

优先Map.of()

---

十一、实际开发场景

配置项返回

例如：

public Map<String,String> getConfig() {

    return Collections.unmodifiableMap(
            configMap
    );
}

---

防止调用方：

config.put(...)

修改配置。

---

缓存数据暴露

例如：

public Map<Long,User> getCache() {

    return Collections.unmodifiableMap(
            cache
    );
}

---

保护内部缓存。

---

SDK设计

很多开源框架：

Spring

MyBatis

Dubbo

都大量使用：

Collections.unmodifiableXXX

暴露只读集合。

---

十二、面试高频问题

面试题1

unmodifiableMap是真正不可变Map吗？

答案：

不是

---

面试题2

本质是什么？

答案：

只读视图（Read Only View）

---

面试题3

为什么修改原Map会影响结果？

答案：

底层引用同一个Map

---

面试题4

put为什么报错？

答案：

直接抛出

UnsupportedOperationException

---

面试题5

如何实现真正不可变Map？

答案：

Guava ImmutableMap

JDK9 Map.of()

---

面试题6

unmodifiableMap时间复杂度是多少？

创建过程：

O(1)

因为：

没有复制数据

---

十三、最佳实践

推荐：

return Collections.unmodifiableMap(
        cacheMap
);

---

用于：

保护内部数据

---

如果需要真正不可变：

推荐：

Map.of(...)

或者：

ImmutableMap

---

避免误以为：

unmodifiableMap

能够阻止：

原Map修改

实际上：

做不到

---

总结

Collections.unmodifiableMap 的本质：

只读Map视图

而不是：

真正不可变Map

其核心实现：

this.m = m;

只是持有原Map引用。

因此：

修改原Map

会影响只读Map

但：

put()
remove()
clear()

等修改操作会直接抛出：

UnsupportedOperationException

牢记一句面试经典回答：

Collections.unmodifiableMap本质上是一个只读包装器（Wrapper），它并不会复制底层数据，而是持有原Map引用，因此只能限制当前视图修改数据，无法阻止原Map发生变化。

---