在Java里如何使用HashMap与HashSet_Java集合核心类解析

必须。自定义类作HashMap键时，不重写hashCode()和equals()会导致相同业务对象无法识别为同一键，因默认方法基于内存地址；二者必须同时重写以满足哈希契约，推荐IDE生成或Lombok注解。

HashMap 的键必须重写 hashCode() 和 equals() 吗？

必须。如果自定义类作为 HashMap 的键，且未重写这两个方法，会导致逻辑错误：相同业务含义的对象无法被正确识别为同一键，put() 可能重复插入，get() 返回 null。

原因在于 HashMap 查找时先用 hashCode() 定位桶位置，再用 equals() 比较链表/红黑树中的节点。默认的 Object.hashCode() 返回内存地址，equals() 也是引用比较。

• 只重写 hashCode() 不重写 equals()：不同对象可能哈希值相同，但 equals() 返回 false，导致查不到已存的键
• 只重写 equals() 不重写 hashCode()：违反契约——相等对象必须有相同哈希值，JDK 会直接破坏哈希表结构（如 get() 永远找不到）
• 推荐用 IDE 自动生成（如 IntelliJ 的 Alt+Insert → equals() and hashCode()），或使用 Lombok 的 @EqualsAndHashCode

HashSet 底层真是用 HashMap 实现的？

是的。JDK 8 中 HashSet 的源码明确显示它内部持有一个 HashMap 实例：

private transient HashMap map;
private static final Object PRESENT = new Object(); // 占位值

所有 add(e) 操作本质是 map.put(e, PRESENT)；contains(e) 是 map.containsKey(e)；remove(e) 是 map.remove(e)。所以 HashSet 的性能、线程安全性、null 支持等特性完全继承自其底层 HashMap。

立即学习“Java免费学习笔记（深入）”；

Whimsical

Whimsical推出的AI思维导图工具

下载

• HashSet 允许存一个 null 元素，因为 HashMap 允许 null 键
• HashSet 无序，但不是“随机”——它的遍历顺序取决于底层 HashMap 的桶数组和链表/树结构，与插入顺序无关
• 想保持插入顺序？改用 LinkedHashSet，它底层是 LinkedHashMap

HashMap 在高并发下直接用会出什么问题？

JDK 8 之前（如 JDK 7），多线程 put() 可能触发扩容时的环形链表，造成 get() 死循环；JDK 8 虽修复了环形链表，但仍然**不保证线程安全**：丢失更新、size 计算错误、数据覆盖仍会发生。

• 不要用 Collections.synchronizedMap(new HashMap()) 做简单包装——它只同步单个方法，复合操作（如 if (!map.containsKey(k)) map.put(k, v);）仍是竞态
• 真正需要并发写的场景，优先选 ConcurrentHashMap；它分段锁（JDK 7）或 CAS + synchronized（JDK 8+），支持高并发读写
• 如果只是读多写少，且写操作可串行化，可用 CopyOnWriteArrayList 思路自己封装，但注意 HashMap 本身不支持 copy-on-write

为什么 HashMap 的初始容量建议设为 2 的幂？

因为 HashMap 计算索引用的是 (n - 1) & hash（n 是桶数组长度），这等价于取模 hash % n，但前提是 n 是 2 的幂。否则位运算结果分布不均，哈希碰撞激增，性能退化为链表查找。

• 构造时传 initialCapacity = 10，实际分配的数组长度会自动向上取到最近的 2 的幂（即 16）
• 如果预估要存 1000 个元素，按默认加载因子 0.75，应设初始容量为 1000 / 0.75 ≈ 1334，再取 2 的幂 → 2048
• 过度设大（如直接设 65536）浪费内存；过小（如始终用默认 16）导致频繁扩容（rehash），每次都要重新计算所有 key 的位置

实际开发中，最容易被忽略的是：把可变对象（如 ArrayList、自定义含可变字段的类）当作 HashMap 的键。一旦键对象内容改变，其 hashCode() 可能变化，导致该键永远无法被 get() 或 remove() 到——它被“锁死”在旧桶里了。