hashmap通过扰动函数hash()（高16位异或低16位）优化哈希分布，再用(n-1)&hash定位桶；扩容时利用位运算特性实现高效迁移；链表转红黑树需同时满足容量≥64且链表长度≥8；get返回null不表示键不存在，因value可为null；非线程安全，多线程下可能出现数据丢失、可见性问题等。
HashMap put操作时如何计算桶位置
Java 8 的 HashMap 不是直接用 hashCode() 对数组长度取模，而是先做一次扰动运算再与操作：(n - 1) & hash，其中 n 是数组容量（必须是 2 的幂），hash 是经过 hash() 方法扰动后的值。
这个扰动函数实际就是：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}目的是让高16位也参与低位索引计算，避免低比特位分布不均导致大量哈希冲突。
- 如果键的
hashCode()都集中在低位（比如只改变最后几位），未扰动时所有键可能落到同一个桶里 - 数组扩容后
n变为原来的两倍，(n - 1)的二进制多一位，但旧桶中的元素只需判断新增那一位是 0 还是 1，就能决定留在原位还是移到oldCap + index—— 这就是 Java 8 扩容不重哈希的关键
链表转红黑树的两个硬性条件
不是只要链表长度 ≥ 8 就转树，必须同时满足：
-
table数组长度 ≥ 64 - 当前桶中链表节点数 ≥ 8
前者是为了避免在小容量下过早树化带来额外开销；后者是触发树化的阈值。反向操作（树转链表）则只要节点数 ≤ 6 就退化，且无需检查容量。
注意：TreeNode 是 Node 的子类，但树化后整个桶的结构从 Node 链表变成 TreeNode 红黑树，查找时间复杂度从 O(n) 降到 O(log n)，但插入/删除代价更高。
立即学习“Java免费学习笔记（深入）”；
get操作为什么可能返回null却不表示键不存在
get(null) 或 get(key) 返回 null 有两种可能：
- 键确实不存在
- 键存在，但对应值就是
null
因为 HashMap 允许 null 作为 value（也允许一个 null key）。所以不能靠 get(k) == null 判断键是否存在，得用 containsKey(k)。
另外，get 内部仍会调用 hash() 计算扰动值，对 null key 直接返回 0，所以它总落在 table[0] 桶里（前提是数组已初始化）。
并发场景下HashMap的典型失效表现
HashMap 不是线程安全的，多线程 put 可能引发：
- 死循环（Java 7 中扩容时链表头插法导致环形链表，CPU 100%）
- 数据丢失（两个线程同时触发 resize，其中一个的写入被覆盖）
- 读到过期值（缺少 volatile / happens-before，新写入对其他线程不可见）
Java 8 改为尾插法，消除了死循环，但仍然不保证线程安全。需要并发写入时，应选 ConcurrentHashMap；仅读多写少且可接受弱一致性，可用 Collections.synchronizedMap()，但吞吐量差很多。
真正容易被忽略的是：即使你只读不写，若其他线程正在扩容，get 仍可能看到部分迁移中、结构不一致的桶 —— 这不是 bug，是未同步导致的内存可见性问题。
