为什么 Collections.unmodifiableMap 不能防住所有修改
它只是包了一层“拒绝写操作”的代理，底层数组或哈希表本身没变。如果原始 Map 还在别处被改，只读视图会立刻反映出那些变更——这不是 bug，是设计使然。
- 常见错误现象：
UnmodifiableMap里 key 对应的 value 是可变对象（比如ArrayList），外部仍能调用value.add(...)，字典内容“看似没变”，实际逻辑数据已脏 - 使用场景：适合保护 Map 结构本身不被 put/remove/clear，但不等于冻结整个数据树
- 正确做法：必须确保传入的原始
Map不再被其他代码持有引用，或提前用new HashMap(original)做一次浅拷贝
怎么安全地构造真正只读的嵌套结构
当 value 是 List、Set 或自定义对象时，Collections.unmodifiableMap 不会递归处理它们。你得手动“层层封印”。
- 参数差异：没有自动深只读选项，
unmodifiableMap的签名是unmodifiableMap(Map extends K, ? extends V> m)，泛型擦除后它对V类型一无所知 - 实操建议：对每个 value 单独包装，例如
Map.of("items", Collections.unmodifiableList(items)) - 性能影响：每次 get 都返回新一层不可变视图，开销极小；但若频繁构造大量嵌套只读结构，注意避免重复包装同一集合
UnmodifiableMap 在序列化和并发场景下的表现
它实现了 Serializable，但反序列化后得到的是普通 HashMap，不再是只读的——这点极易被忽略。
- 常见错误现象：把
unmodifiableMap存进 Redis 或写到文件，读回来直接能put，防护失效 - 并发安全：它本身线程安全（无状态代理），但不解决底层 map 的并发问题；如果原始 map 是非线程安全的，多线程读+单线程写仍可能触发
ConcurrentModificationException - 替代方案：需要真正线程安全 + 只读，优先考虑
Map.copyOf(map)（Java 10+）或ImmutableMap.ofEntries(...)（Guava）
用 Map.copyOf 替代 unmodifiableMap 的时机
如果你不需要原始 map 的后续变更同步到只读视图，Map.copyOf 更干净——它生成的是独立快照，且 JDK 自带、无额外依赖。
立即学习“Java免费学习笔记（深入）”；
- 兼容性：仅限 Java 10+；低于此版本只能手写
new HashMap(m)再 wrap - 行为差异：
copyOf会立即复制键值对，之后原始 map 怎么变都无关；而unmodifiableMap是实时代理 - 容易踩的坑：传
null给copyOf会抛NullPointerException，而unmodifiableMap允许 null 参数（但运行时调用方法会炸）
真正难的不是加个 unmodifiableMap，而是判断“只读”到底要守住哪一层边界：是结构？引用？还是整个对象图的不可变性。这个边界一旦划错，后面所有防护都成摆设。
