hash()扰动函数不可省，因其将高16位异或进低16位，避免低位规律性导致哈希分布不均；若省略，自增主键等场景下桶分布恶化5–8倍，O(1)退化为O(n)。
hash() 扰动函数为什么不能省？
直接用 key.hashCode() 做索引计算，极容易在低比特位规律性强的场景下崩——比如数据库主键自增（hashCode 就是 1,2,3…）、时间戳毫秒值、或某些 ORM 生成的 ID，它们的低位变化频繁但高位几乎不变。这时未扰动的 hash 值 & (n-1) 实际只用了低几位，导致大量 key 挤在前几个桶里，链表暴涨，O(1) 变成 O(n)。
Java 8 的 hash() 强制把高16位异或进低16位：(h = key.hashCode()) ^ (h >>> 16)，让高位也参与桶定位。实测显示，对连续整数 key，扰动后桶分布均匀度提升 5–8 倍。
- 自定义 key 类必须重写
hashCode()，否则默认Object.hashCode()返回内存地址，不同实例几乎必冲突 - 如果 key 是不可变类（如
String、Integer），不用管；但若用可变对象作 key（如没设 final 的 POJO），后续修改字段会导致hashCode()变，get()就再也找不到它了
put() 时桶位置怎么算？别再用 % 取模
HashMap 不用 hash % table.length，而是用 (table.length - 1) & hash。前提是数组长度必须是 2 的幂（16、32、64…），这样 table.length - 1 就是形如 0b1111 的掩码，位与运算比取模快一个数量级，且无除法开销。
例如容量 16 → 掩码 15（0b1111），hash = 12345（0b11000000111001），12345 & 15 = 9，直接落到索引 9 —— 这就是真实桶下标。
立即学习“Java免费学习笔记（深入）”；
- 扩容时新容量翻倍（如 16→32），掩码多一位（
0b11111），旧桶中每个节点只需看新增那一位是 0 还是 1，就能决定留在原位还是移到oldCap + index，无需重新调用hash() - 如果你手动指定初始容量，别传奇数或质数（如 17、100），要传 2 的幂（
new HashMap(32)），否则构造器会自动向上取到最近的 2 的幂（100 → 128）
链表什么时候转红黑树？两个条件缺一不可
不是链表一长到 8 就树化。必须同时满足：table.length >= 64 且 链表节点数 >= 8。前者是为了避免小容量下树结构带来的额外内存和维护成本（TreeNode 比 Node 大得多），后者才是触发阈值。
反向退化更宽松：只要红黑树节点数 ≤ 6，就立刻转回链表，不检查容量。
- 如果你的应用 key 冲突严重（比如用用户手机号做 key，但部分号段集中），建议初始化时设大点容量（如
new HashMap(1024)），提前规避链表过长 - 树化后
get()查找是 O(log n)，但插入/删除代价更高；高频写、低频读场景慎用树化，可考虑换哈希算法或预分片 - 用
jdk.internal.vm.annotation.Contended等方式缓存行对齐优化，对极端并发场景有帮助，但属于高级技巧，普通业务无需介入
get() 返回 null 到底是没找到，还是 value 就是 null？
两者都可能。HashMap 允许 value 为 null，也允许一个 null key，所以 map.get("xxx") == null 完全无法判断 key 是否存在。
正确姿势是：查存在性用 map.containsKey(key)，查 value 用 map.get(key)，二者语义不同，不可混用。
-
nullkey 固定落在table[0]（因为hash(null) == 0），但前提是 table 已初始化；首次get(null)会触发延迟初始化，这点常被忽略 - 多线程环境下，即使加了同步，
containsKey()和get()之间仍可能被其他线程修改，如需强一致性，得用ConcurrentHashMap或外部锁 - 如果业务逻辑里 value 绝对不允许为 null，建议用 Optional 包装，或统一约定用特殊哨兵值（如 -1、""），从源头堵住歧义
真正容易被忽略的是：扰动函数虽小，却是整个哈希分布的基石；而 containsKey() 和 get() 的语义差异，在复杂条件分支里一旦写错，debug 成本远高于预防成本。
