hashmap本质是“数组+链表/红黑树”，通过hashcode()定位桶、equals()判定键重复，put/get依赖确定性三步链路：计算哈希值→位运算得索引→equals()比对确认键。
HashMap 本质是“数组 + 链表/红黑树”的哈希寻址结构，靠 hashCode() 定位桶、equals() 判定键是否重复——不是简单“存进去就能取”，而是每次 get() 或 put() 都在做两次关键判断。
为什么 put("a", 1) 后 get("a") 能立刻拿到值？
因为整个过程是确定性的三步链路：
- 调用
"a".hashCode()得到一个整数（比如 97）； - 用这个哈希值和当前
table数组长度做位运算（(n - 1) & hash），快速算出下标（比如落到索引3）； - 检查
table[3]是否为空：为空则新建Node存入；不为空，则遍历链表或树，用key.equals()逐个比对——只有equals()返回true才视为“同一个键”。
注意：hashCode() 冲突 ≠ 键相等。两个不同字符串可能哈希码相同（如 "Aa" 和 "BB"），但只要 equals() 不通过，它们就是不同的键，会共存于同一桶中。
链表什么时候变红黑树？阈值不是固定 8 就完事
Java 8+ 中，链表转红黑树需同时满足两个条件：
立即学习“Java免费学习笔记（深入）”；
- 链表长度 ≥
8（即桶里已有 8 个节点）； - 当前
table数组长度 ≥64（即总桶数不少于 64）。
如果数组才 16 个桶，哪怕某条链长到了 10，也不会转树——因为此时更该做的是扩容（resize()），而不是升级数据结构。这是为避免小容量下过早引入红黑树的维护开销。
static final int TREEIFY_THRESHOLD = 8; static final int MIN_TREEIFY_CAPACITY = 64;
自定义类作 key 时，不重写 hashCode() 和 equals() 会怎样？
现象很隐蔽：你反复 put(new User("Alice"), 100)，但 get(new User("Alice")) 总返回 null。
原因在于默认 Object.hashCode() 返回对象内存地址，每次 new 都是新地址；而默认 equals() 只比较引用。结果就是：逻辑上相同的对象，在 HashMap 看来既不在同一个桶，也不等于已有键。
正确做法（以 Lombok 为例）：
@Data
@EqualsAndHashCode(of = "id") // 明确只用 id 字段参与 equals/hashCode
public class User {
private Long id;
private String name;
}务必确保：相等的两个对象（equals() == true）必须有相同 hashCode()；反之不强制，但散列越均匀，冲突越少。
扩容（resize）到底动了哪些东西？
扩容不是“把老数组复制过去”那么简单，它会：
- 创建一个两倍大小的新
table（如从 16 → 32）； - 重新计算每个已有
Node的哈希值，并用新数组长度再算一次桶索引； - 由于新长度变了，原来
table[3]的节点，可能被分到newTable[3]和newTable[19]（高位 bit 影响结果）。
所以扩容代价不小，尤其当大量元素已存在时。这也是为什么建议预估容量：比如你知道要存 1000 个键值对，就别用默认 16，直接 new HashMap(1024)（1024 是 2 的幂，且 > 1000 / 0.75）。
最常被忽略的一点：HashMap 的“无序”不是指随机，而是完全由哈希值和扩容历史决定——同一批数据，在不同 JVM 实例、不同 JDK 版本、甚至不同启动参数下，遍历顺序都可能不同。别依赖 keySet() 的顺序做业务逻辑。
