Java HashMap 1.7与1.8核心差异在于哈希冲突优化：1.7用数组+单向链表、头插法、全量rehash；1.8升级为数组+链表+红黑树、尾插法、位运算分治扩容，并优化哈希算法与节点设计。
Java 中 HashMap 1.7 和 1.8 的底层实现差异，核心在于**如何应对哈希冲突带来的性能退化问题**，以及由此引发的数据结构、插入逻辑、扩容机制和线程安全前提下的设计演进。不是简单“加了个红黑树”，而是整套存储与查找逻辑的重构。
数据结构：从纯链表到链表+红黑树
JDK 1.7 使用 数组 + 单向链表（Entry 结构），所有哈希冲突都靠链表串联，查询需遍历，最坏时间复杂度 O(n)；
JDK 1.8 改为 数组 + 链表 + 红黑树（Node / TreeNode），当某个桶中链表长度 ≥ 8 且 数组长度 ≥ 64 时，自动转为红黑树，查找降为 O(log n)；若树中节点数 ≤ 6，则退化回链表。
插入方式：头插法 vs 尾插法
1.7 采用头插法：新节点总插入链表头部，虽利于热点 key 快速命中，但扩容时易因多线程重哈希导致链表倒置、成环，引发死循环（经典 bug）；
1.8 改用尾插法：新节点追加到链表末尾，保证插入顺序，彻底规避成环风险，也使遍历行为更可预测。
扩容机制：全量 rehash vs 位运算分治
1.7 扩容时，对每个元素重新计算 hash 值再取模，确定新下标，开销大且无法复用旧计算结果；
1.8 利用数组长度必为 2 的幂这一特性，通过 (e.hash & oldCap) == 0 判断：结果为 0 表示留在原位置，否则新下标 = 原下标 + oldCap，无需重新哈希，效率更高，也自然保持插入顺序。
哈希算法与节点设计
1.7 的 hash 计算较复杂，部分类型（如 String）有专用优化，且 Entry 中 hash 字段非 final，允许扩容时重算；
1.8 统一使用 h = key.hashCode()，然后 h ^ (h >>> 16)，高位参与扰动，散列更均匀；Node 中 hash 为 final，一经确定不再变更；节点类型也从 Entry 统一为 Node，树节点则封装为 TreeNode，结构更清晰、职责更单一。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
