必须。自定义类作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<E, Object> 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免费学习笔记（深入）”；
-
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() 到——它被“锁死”在旧桶里了。
