HashMap put过程：先计算hash并确定下标，空则直接插入；非空则先equals比对，相等覆盖value，不等再处理哈希冲突；key为null固定放索引0；自定义key须重写hashCode和equals且保持一致；修改影响hashCode的字段会导致get失败；链表转红黑树需同时满足桶内长度≥8且数组长度≥64；扩容触发条件为size>threshold，新容量翻倍并全量rehash；get平均O(1)，最坏O(log n)（红黑树）或O(n)（链表）。
HashMap 的 put 过程到底发生了什么
往 HashMap 里放一个键值对，不是简单地算个 hash 然后塞进数组。它实际会走一整套判断链：先算 hash(key)，再用这个值和数组长度做与运算得到下标；如果该位置为空，直接新建 Node 放进去；如果不为空，得先比对 key 是否相等（equals()），相等就覆盖 value；不相等才考虑哈希冲突处理。
常见错误现象：put 后取不到刚存的值，大概率是 key 的 hashCode() 和 equals() 没写一致——比如只重写了 hashCode()，或者两个方法逻辑矛盾。
- 自定义类作 key 时，必须同时重写
hashCode()和equals()，且保证“相等的 key 一定有相同 hash 值” -
key为null是特例：它总被放在数组索引 0 的位置，且只允许一个nullkey - 不要在 key 对象存入后修改影响
hashCode()的字段，否则后续get()找不到——因为 hash 值变了，查的就不是原来那个桶了
链表转红黑树的阈值和触发条件
当某个桶里链表长度达到 8，且整个 HashMap 的数组长度 ≥ 64 时，才会把链表转成红黑树。这两个条件缺一不可。
为什么不是“只要链表够长就转”？因为小容量数组下，链表长更多是扩容没跟上，而不是真有大量哈希冲突；盲目转树反而增加维护开销。而数组 ≥ 64 意味着哈希分布本应比较均匀，此时还出现长度 ≥ 8 的链表，更可能是 key 的 hashCode() 实现不合理或数据本身有偏态。
立即学习“Java免费学习笔记（深入）”；
- 可通过
-XX:AutoBoxCacheMax=200等 JVM 参数间接影响 Integer 等缓存对象的 hash 分布，但不建议这么调 - 若频繁触发树化，优先检查 key 类型的
hashCode()是否过于集中（比如只返回固定值或低比特全零） - 红黑树退化回链表的阈值是
6，不是7或8的一半——这是为了防止在7附近反复树化/退化造成抖动
扩容机制如何影响性能和线程安全
HashMap 在 size > threshold（即 capacity × loadFactor）时触发扩容，新容量是原来的 2 倍，并重新计算所有已有元素的位置。这个过程是全量 rehash，时间复杂度 O(n)，且期间整个 map 不可用。
容易踩的坑是：初始化时没预估大小，导致频繁扩容。例如已知要存 1000 个元素，用默认构造函数（初始容量 16，负载因子 0.75），会触发约 6 次扩容，每次都要搬运之前所有元素。
- 推荐显式指定初始容量：
new HashMap(1024)，让threshold = 1024 × 0.75 = 768，可容纳 768 个元素不扩容 - 扩容不是线程安全的：多线程
put可能引发死循环（JDK 7）或数据丢失（JDK 8+），必须用ConcurrentHashMap替代 -
loadFactor设太小（如 0.5）会浪费内存；设太大（如 0.9）则链表/树更易变长，查找变慢——0.75 是空间与时间的平衡点，一般别动
为什么 get 操作在 JDK 8 后平均是 O(1)，但最坏是 O(log n)
理想情况下，hash 均匀、无冲突，get 就是算 hash + 定位桶 + 直接取值，O(1)。但一旦发生哈希冲突，就得在桶内遍历；如果是链表，最坏 O(n)；如果是红黑树，最坏 O(log n)。
注意：这里的“最坏”不是指整个 map 只有一个桶，而是单个桶内节点数很多。而红黑树的 O(log n) 是相对于该桶内节点数而言，不是整个 map 大小。
- 即使开了树化，也改变不了“哈希设计差 → 冲突集中 → 单桶节点爆炸”的根本问题
- 用
System.identityHashCode()代替自定义hashCode()并不能解决业务语义上的冲突，只是换了一种 hash 方式 - 调试时可用
map.size()和map.entrySet().stream().map(e -> e.getKey().hashCode()).distinct().count()粗略看 hash 分布是否离散
哈希冲突本身不可消除，只能缓解；真正决定性能上限的，从来不是“用了红黑树”，而是 key 的 hash 函数质量、数据分布特征、以及你有没有在一开始就避开明显陷阱。
