- 正确答案：ConcurrentHashMap 和 Hashtable 都是线程安全的哈希表实现，用于多线程环境下存储键值对。它们的主要区别在于实现线程安全的方式、性能表现以及功能扩展性。ConcurrentHashMap 使用分段锁（JDK 7）或 CAS + synchronized（JDK 8 及以后），而 Hashtable 使用全局同步（即每个方法都加 synchronized）。因此，在高并发场景下 ConcurrentHashMap 性能远优于 Hashtable。 - 解答思路： 1. 明确问题核心：比较 ConcurrentHashMap 与 Hashtable 的异同。 2. 分析两者如何实现线程安全。 3. 对比性能、迭代器行为、null 值支持、底层数据结构等关键维度。 4. 结合实际应用场景说明为何推荐使用 ConcurrentHashMap 替代 Hashtable。 5. 深入底层机制，解释其并发控制原理。 - 深度知识讲解：一、线程安全机制对比 1. Hashtable： - 所有公共方法（如 get、put、remove）都被 synchronized 修饰。 - 这意味着任意时刻只有一个线程可以访问 Hashtable 的任何方法，造成严重的竞争和阻塞。 - 锁粒度为整个对象，属于“悲观锁”策略。 - 示例代码片段（概念级）： ``` public synchronized V get(Object key) { // ... } public synchronized V put(K key, V value) { // ... } ``` 2. ConcurrentHashMap（以 JDK 8 为例）： - 不采用全局锁，而是基于 Node 数组 + 链表/红黑树实现，并在必要时使用 synchronized 锁住单个桶（bucket）。 - 插入、更新操作中大量使用 CAS（Compare-And-Swap）原子操作来避免显式加锁。 - 锁粒度极小，仅锁定当前冲突的桶，允许多个线程同时读写不同桶。 - 支持更高的并发读写性能。核心结构（JDK 8）： - 底层是一个 Node[] table，类似于 HashMap。 - 每个桶的第一个节点作为 synchronized 锁的对象。 - 当链表长度超过阈值（默认 8）且数组长度大于 64 时，转换为红黑树（TreeBin）提高查找效率。关键源码逻辑示意（简化版）： ``` final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); int binCount = 0; for (Node[] tab = table;;) { Node f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 尝试用 CAS 插入第一个节点 if (casTabAt(tab, i, null, new Node(hash, key, value, null))) break; } else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); else { V oldVal = null; synchronized (f) { // 只锁当前桶 if (tabAt(tab, i) == f) { if (fh >= 0) { binCount = 1; for (Node e = f;; ++binCount) { K ek; if (e.hash == hash && ((ek = e.key) == key || (ek != null && key.equals(ek)))) { oldVal = e.val; if (!onlyIfAbsent) e.val = value; break; } Node pred = e; if ((e = e.next) == null) { pred.next = new Node(hash, key, value, null); break; } } } // 红黑树处理略... } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); if (oldVal != null) return oldVal; break; } } } addCount(1L, binCount); return null; } ``` 二、主要特性对比表： | 特性 | Hashtable | ConcurrentHashMap | |--------------------------|------------------------------------|-------------------------------------| | 是否允许 null 键/值 | 否（抛出 NullPointerException） | 否（不允许 null 键或值） | | 线程安全方式 | 全局 synchronized 方法 | CAS + synchronized（桶级锁） | | 默认初始容量 | 11 | 16 | | 扩容机制 | 扩容为原大小 * 2 + 1 | 扩容为原来的两倍（类似 HashMap） | | 迭代器是否 fail-fast | 是（但遍历时仍可能有问题） | 是（但支持弱一致性迭代器） | | 并发度（最大并发写线程数）| 1（串行写） | 多（可多个线程同时写不同 segment/桶）| | 性能 | 低（高竞争下严重阻塞） | 高（细粒度锁+CAS优化） | | 是否被废弃 | 不完全废弃，但不推荐使用 | 推荐使用的并发 Map | 三、fail-fast 与弱一致性迭代器 - Hashtable 的迭代器是 fail-fast 的：如果在迭代过程中其他线程修改了 map，会抛出 ConcurrentModificationException。 - ConcurrentHashMap 的迭代器是**弱一致性**的： - 不保证反映最新的修改。 - 不抛出 ConcurrentModificationException。 - 允许在遍历时其他线程进行更新操作。 - 适用于大多数并发场景下的“最终一致”需求。四、历史演进（JDK 7 vs JDK 8）在 JDK 7 中，ConcurrentHashMap 使用 Segment 分段锁机制： - 内部将数据分为多个 Segment（继承 ReentrantLock），每个 Segment 相当于一个小型 Hashtable。 - 默认 16 个 Segment，最大并发写线程为 16。 - put 操作先定位到 Segment，再在其内部加锁。 - 虽然比 Hashtable 好，但仍存在内存占用大、扩展性差等问题。 JDK 8 彻底重构： - 移除 Segment，改用 CAS + synchronized 控制单个桶。 - 更轻量、更高效，尤其在低冲突场景下接近非同步容器性能。五、为什么不要用 Hashtable？ 1. 性能瓶颈明显：所有操作串行化。 2. 功能落后：没有提供现代并发编程所需的高级 API（如 computeIfAbsent、merge 等）。 3. 设计陈旧：自 Java 5 引入 java.util.concurrent 包以来，Hashtable 已被视为遗留类。 4. 推荐替代方案：ConcurrentHashMap 或 Collections.synchronizedMap(new HashMap<>())（后者仍为全锁，但更灵活）。六、适用场景建议 - 单线程环境：使用 HashMap。 - 多线程读多写少：可考虑使用 Collections.synchronizedMap(new HashMap<>())。 - 高并发读写：必须使用 ConcurrentHashMap。 - 需要强一致性遍历：需额外加锁或使用 CopyOnWriteMap（特殊场景）。 - 缓存、计数器、共享状态管理：优先选择 ConcurrentHashMap。 - 扩展知识点： 1. CAS 原理（Compare-And-Swap）： - 是一种无锁算法，依赖 CPU 指令（如 x86 的 cmpxchg）实现原子更新。 - 在 ConcurrentHashMap 中用于设置头节点、初始化 table 等。 - ABA 问题可通过 AtomicStampedReference 解决（但 ConcurrentHashMap 不需要）。 2. volatile 的作用： - 在 ConcurrentHashMap 中，table 数组引用声明为 volatile，确保多线程间可见性。 - Node 的 val 和 next 字段也可能是 volatile，保证读取最新值。 3. size() 方法的实现差异： - Hashtable：直接返回私有变量 size，每次修改同步更新。 - ConcurrentHashMap：不能简单维护一个全局 size，因为并发修改频繁。 - JDK 8 中通过一个 volatile long baseCount 和一个 CounterCell 数组来统计。 - 类似 LongAdder 的思想，减少争用。 - size() 返回的是近似值（long 值截断为 int 可能溢出，故返回 long）。示例伪代码： ``` class ConcurrentHashMap { private transient volatile long baseCount; private transient volatile CounterCell[] counterCells; final long sumCount() { long sum = baseCount; CounterCell[] as = counterCells; if (as != null) { for (CounterCell a : as) if (a != null) sum += a.value; } return sum; } } ``` 4. 与 synchronizedMap 的区别： - Collections.synchronizedMap(new HashMap<>()) 提供的是包装器模式，所有方法加 synchronized。 - 依然是全表锁，性能不如 ConcurrentHashMap。 - 但在某些需要完全同步语义的场景下仍有用途。 - 总结： ConcurrentHashMap 是现代 Java 并发编程中的标准选择，它通过细粒度锁和 CAS 操作实现了高性能的线程安全 Map。而 Hashtable 由于其粗粒度的同步机制，在高并发场景下性能低下，已被淘汰。面试中若被问及两者区别，应重点强调并发控制机制、性能差异、null 值限制以及迭代器行为，并能深入剖析其底层实现原理，尤其是 JDK 8 的优化设计。

新凯来一面

全站热榜

创作者周榜