是的，putAll会覆盖已有key的值；因其内部遍历源map并逐个调用put方法，而put在键存在时必然替换旧值，故putAll具有相同覆盖语义。
put() 方法怎么写才不会覆盖已有键
HashMap 的 put() 方法在键已存在时会直接替换旧值，这不是 bug，而是设计行为。如果你不确定键是否存在、又想避免意外覆盖，得先用 containsKey() 判断，或者改用 putIfAbsent()（Java 8+）。
常见错误是循环里反复 put("user", obj)，结果只留下最后一次赋值。实际场景比如缓存用户配置，应确保 key 唯一且语义明确，例如用 "user_" + userId 而非固定字符串。
-
put()返回的是被替换的旧值（可能为null），可用来做存在性判断：Object old = map.put(key, val); if (old == null) { /* 新增 */ } - 键对象必须正确重写
hashCode()和equals()，否则即使内容相同也会被视为不同键 - 并发环境下不能直接用
HashMap.put()，会出错；应换ConcurrentHashMap或加锁
get() 方法返回 null 到底是没找到还是存了 null
get() 返回 null 有两种可能：键不存在，或该键显式存过 null 值。这是 HashMap 的固有限制，无法单靠返回值区分。
典型踩坑场景：从数据库查一条记录封装进 Map，字段为空时存了 null，后续用 get() 判空就误以为数据缺失。解决方法是优先用 containsKey() 确认键是否存在，再决定是否取值。
- 不要写
if (map.get("name") == null)来判断字段是否存在 - 改用
if (!map.containsKey("name"))或 Java 8+ 的map.getOrDefault("name", "") - 如果业务逻辑允许，尽量避免往 HashMap 存
null值，减少歧义
key 是自定义对象时 get() 总是找不到
自定义类作 key 时，get() 失败几乎全是 hashCode() 和 equals() 没写对导致的。HashMap 查找依赖哈希桶定位 + 链表/红黑树中逐个 equals() 比较，缺一不可。
例如定义 User 类作 key，但只重写了 equals()，没重写 hashCode()，那两个逻辑相等的对象可能散列到不同桶里，get() 根本不会去比对。
- IDE 通常能自动生成这两个方法（IntelliJ 快捷键 Alt+Insert，Eclipse 是 Source → Generate hashCode() and equals()）
- 参与
hashCode()和equals()计算的字段，必须是构造后不可变的；否则对象存入 Map 后修改了这些字段，之后get()就失效 - 推荐用 record（Java 14+）或 Lombok 的
@EqualsAndHashCode减少手写错误
put() 和 get() 的性能到底受什么影响
理想情况下 put() 和 get() 都是 O(1)，但实际取决于哈希分布和负载因子。当大量 key 哈希冲突（都落到同一个桶），链表变长，最坏退化成 O(n)；Java 8 后链表长度超 8 且桶数 ≥64 会转红黑树，降到 O(log n)。
所以不是“用了 HashMap 就一定快”，初始化时预估容量很重要。例如你知道要存 1000 个元素，别用默认容量 16，应设为 new HashMap(1024)（1000 / 0.75 ≈ 1333，向上取 2 的幂）。
- 扩容触发条件是
size > capacity * loadFactor（默认 0.75），每次扩容要 rehash，开销不小 - 如果 key 的
hashCode()总返回常量（如始终 return 1），所有 put 都挤在一个桶，性能急剧下降 - 遍历建议用
entrySet()而非keySet()+get()，后者每次 get 都是一次哈希查找
用对 put() 和 get() 不难，难的是理解它们背后对 key 的契约要求和运行时行为边界。尤其是自定义 key 和 null 值处理，线上出问题往往就卡在这两处。
