源码级剖析：Java 集合框架大版图与并发容器避坑指南

前言 集合框架（Collection Framework）是 Java 开发者每天都在打交道的老朋友，但能把源码底层逻辑说透的人却寥寥无几。为什么 HashMap 容量必须是 2 的次幂？并发扩容为何会导致死链？for-each 遍历删除为何频繁抛出异常？本文将带你撕开 Java 集合的底层伪装，深度拆解大厂面试中永远的 VIP 考点：HashMap 底层演进与 ConcurrentHashMap 的并发魔法。

一、 单列集合 (Collection)：List 与 Set 的生存法则

数组虽然访问极快，但长度固定且只能存同类数据。为了应对复杂多变的业务场景，Java 提供了动态扩容的集合体系。

1. List 体系：ArrayList 绝对主力与 LinkedList 的误区

在日常开发中，我们几乎 90% 的场景都在使用 ArrayList，它的底层是动态数组（内存连续）。

• 扩容机制：第一次 add 时初始化容量为 10；当容量不足时，默认扩容为原容量的 1.5 倍。这是一个基于“空间占用”与“频繁拷贝性能损耗”的完美折中。

• 致命隐患：非线程安全。多线程并发 add 时，不仅会发生数据覆盖，还可能因为同时判定不需要扩容，导致数组越界异常 (OutOfBounds)。

💡 避坑指南：很多老教程推荐“频繁增删用 LinkedList，查询用 ArrayList”。但在现代工业界，由于 LinkedList 内存分散，对 CPU 缓存（CPU Cache Line）极度不友好，且每次插入都需要 new 节点，导致大量内存碎片。除非是纯粹的头尾队列操作，否则即便有增删，依然首推 ArrayList。

2. Set 体系：如何优雅地实现无重复？

Set 的本质就是“不要 Value 的 Map”。它完全利用 Map 的 Key 来实现元素的唯一性。

• HashSet（无序）：底层完全是 HashMap。当你 add 一个元素时，实际上是把它作为 Key 存入了内部的 HashMap，而 Value 则统一填入一个固定的 Object 常量 (private static final Object PRESENT = new Object();)。

• LinkedHashSet（插入有序）：底层是 LinkedHashMap，在哈希表的基础上额外加了双向链表，保证了元素的插入顺序。

• TreeSet（自动排序）：底层是 TreeMap（红黑树），可以根据元素的自然顺序或自定义比较器进行自动排序。

二、 迭代器与 Fail-Fast 机制：遍历删除的“连环坑”

在使用增强 for 循环（底层也是迭代器）遍历集合时，如果直接调用 list.remove() 删除元素，会瞬间抛出 ConcurrentModificationException（并发修改异常）。

1. 底层原理：两个记账本的冲突

• modCount：集合自带的变量，记录集合被修改的实际总次数（总部的账本）。

• expectedModCount：迭代器创建时复制的变量，记录预期修改次数（导游手里的复印件）。

每次获取下一个元素前，迭代器都会核对 modCount == expectedModCount。直接用 list.remove() 修改集合会导致总部账本 modCount++，账本不一致，迭代器立刻“自爆”报错（Fail-Fast 机制）。

💡 避坑指南（倒数第二个元素陷阱）： 如果你在 for-each 中刚好删除了倒数第二个元素，程序竟不会报错！因为删除后，集合的 size 变小，刚好等于当前迭代器的游标位置。下次判断 hasNext() 时直接返回 false，循环提前结束，完美跳过了 modCount 的检查。这会造成极难排查的静默逻辑 Bug。

正解：必须调用 iterator.remove()，它不仅会删除底层元素，还会同步更新自己手里的 expectedModCount。如果在 Java 8+，推荐直接使用 list.removeIf()。

三、 字典之王 HashMap：底层演进与寻址魔法

HashMap 是 Java 性能调优和面试的核心战区。理解它，才算真正迈入 Java 底层的大门。

1. 数据结构的史诗级演进

• JDK 1.7：数组 + 链表（头插法）。

  • 致命隐患：多线程并发扩容时，头插法极易导致链表反转，形成环形死链，瞬间打满服务器 CPU。

• JDK 1.8：数组 + 链表 + 红黑树（尾插法）。

  • 引入尾插法解决了死循环问题。

  • 树化条件（高频考点）：当 链表长度 ≥ 8 且 数组总容量 ≥ 64 时，链表会转化为红黑树，将查询时间复杂度从 O(n) 降到 O(log n)。如果只满足链表 ≥ 8 但数组容量 < 64，HashMap 会优先选择扩容数组而不是树化。

2. 核心参数的数学之美

• 负载因子为何是 0.75？ 这是基于泊松分布算出的完美概率点。0.5 太浪费空间，1.0 哈希冲突概率太高。0.75 完美权衡了“空间利用率”与“哈希冲突概率（时间效率）”。

• 容量为何必须是 2 的次幂？ 底层不再使用慢速的 % 取模运算，而是利用 (n - 1) & hash 的位运算极速定位元素存放的桶下标。只有当容量 n 是 2 的次幂时，n - 1 的二进制才会全是 1，这样能保证按位与的结果完全取决于 hash 值的后几位，实现绝对均匀的分布。

3. JDK 1.8 的扩容极限优化

在 JDK 1.7 中，扩容需要重新计算每个元素的 hash 值。 而在 JDK 1.8 中，由于容量始终是翻倍的（如 16 变 32），扩容时根本不需要重新 hash！只需要看 hash 值的新增高位是 0 还是 1：

• 如果是 0，元素留在原位置。

• 如果是 1，元素直接移动到 原位置 + 旧容量 的新位置。 这种机制避免了大量繁琐的位运算计算，极大提升了扩容效率。

四、 并发集合与锁的艺术：ConcurrentHashMap

由于原生 HashMap 在多线程下存在数据覆盖等问题，高并发系统中必须使用并发容器。

1. ConcurrentHashMap 的锁粒度演进

• JDK 1.7（分段锁）：采用 Segment 数组，将一个大哈希表切分成 16 个独立的段。最多支持 16 个线程并发写入。但这依然是用 ReentrantLock 锁住了一个分段，粒度还是略大。

• JDK 1.8（细粒度锁的巅峰）：彻底摒弃分段锁，直接锁住数组每个桶的头节点。采用了 CAS（无锁操作）+ synchronized 的精细化控制策略：

  • CAS（乐观锁极速写入）：如果目标桶位为空，直接用 CAS 以原子级别放入首个节点，速度极快，完全无锁。

  • synchronized（悲观锁降级）：如果发生哈希冲突（桶位不为空），才使用 synchronized 锁住当前桶的链表或红黑树进行插入。由于现代 JDK 对 synchronized 做了锁升级优化，且锁的粒度细化到了单个桶，并发性能达到了极致。

2. 读多写少的核武器：CopyOnWriteArrayList

除了 Map，高并发 List 的首选是 CopyOnWriteArrayList。

• 核心原理（写时复制）：读操作完全不加锁，直接读取原数组的快照；写操作（增删改）时，会加锁并拷贝出一个全新的数组，在新数组上修改完毕后，再将底层的 volatile 引用指向新数组。

• 适用场景：系统黑名单、白名单配置、路由规则等读极多、写极少、且对实时强一致性要求不高的场景。

• 代价：写操作极慢，且极其消耗内存，容易引发 Full GC。绝对不能用于频繁写入的业务逻辑中。