- 正确答案：HashMap在JDK7和JDK8中均是线程不安全的，主要体现在多线程并发put、resize、get等操作时可能引发数据丢失、死循环（JDK7）、或节点覆盖（JDK8）；ConcurrentHashMap通过分段锁（JDK7）或CAS + synchronized + Node链表/红黑树分桶加锁（JDK8）实现线程安全，保证高并发下的读写一致性与高性能。 - 解答思路：首先明确“线程不安全”的本质——不是指语法错误，而是指在无同步控制下，多个线程对共享状态（如table数组、size、next引用、hash冲突链结构）的并发修改违反了原子性、可见性或有序性，导致不可预测行为。接着分别从JDK7和JDK8的HashMap底层实现切入，定位关键不安全点（如扩容时的头插法环形链、transfer过程竞争、Node.value/Volatile语义缺失等）；再对比ConcurrentHashMap的设计演进：JDK7用Segment分段锁降低锁粒度，JDK8彻底废弃Segment，改用更细粒度的“桶级synchronized”+ CAS控制扩容和初始化，结合volatile修饰的table、sizeCtl、Node.next等字段保障可见性，并引入TreeBin红黑树锁升级机制优化高冲突场景。 - 深度知识讲解： ▶ JDK7 HashMap线程不安全的核心原因（致命死循环）： - 底层结构：数组 + 链表（头插法插入），Entry为静态内部类，next为普通引用（非volatile）。 - 并发put触发resize时，多个线程同时执行transfer()方法； - 头插法特性：新节点总插入链表头部，即 e.next = newTable[i]; newTable[i] = e； - 假设线程A、B同时rehash同一链表 [A→B→C]，各自计算索引后，因指令重排序或执行时序交错，可能构造出环形链表：A→B→C→B（或A→C→A）； - 后续get()遍历该桶时进入无限循环（while (e != null) { ... e = e.next; }），CPU 100%； - 补充：size变量非volatile，且put后未同步更新，导致size统计错误；modCount未做并发保护，fail-fast机制在多线程下失效。 ▶ JDK8 HashMap线程不安全的表现（非死循环，但数据丢失/覆盖）： - 结构升级：Node替代Entry，仍为链表+红黑树（当链表≥8且table≥64时树化）； - 插入改为尾插法（避免JDK7环形问题），但并发put仍不安全： * 两个线程同时检测到table[i]为null，各自new Node并CAS设置table[i] → 其中一个失败，但已构造好Node对象（无副作用）； * 更严重的是：两个线程同时发现table[i]非空（发生哈希冲突），都执行链表遍历+尾插逻辑；若都完成遍历并准备插入，但未加锁，则后执行的线程会覆盖先执行线程的插入结果（因为没有compareAndSetNode操作，纯赋值）； * resize阶段：transfer()使用CAS+for循环迁移，但若两个线程同时看到oldTab[j]==null，跳过；若都看到非null，各自迁移，但Node.next的修改无同步，可能导致部分节点丢失（尤其在迁移中途被另一线程再次put并修改链表结构）； - 关键缺陷：所有字段（table、Node.next、Node.value、Node.hash）除table本身用volatile声明外，其余均无内存屏障保障；Node.value未用volatile，导致其他线程读到过期值；size仍非原子更新（依赖ConcurrentHashMap才用LongAdder）。 ▶ ConcurrentHashMap JDK7实现原理（分段锁 Segment）： - 将整个Hash表逻辑划分为若干Segment（默认16个），每个Segment继承ReentrantLock，封装一个独立的HashEntry数组； - put操作：先根据key.hashCode()定位Segment，再调用其put()（内部加锁）； - get操作：无需加锁，因HashEntry的value和next均为volatile，保证可见性（volatile语义：写volatile变量前所有写操作对后续读该volatile变量的线程可见）； - size()：需遍历所有Segment并累加，为避免锁全部Segment，采用两次尝试+加锁校验策略（若两次sum结果一致则返回，否则锁所有Segment重算）； - 缺陷：Segment数量固定，扩容需全局锁；内存占用高（每个Segment含独立table、count、modCount）；无法完全避免跨Segment的ABA问题。 ▶ ConcurrentHashMap JDK8实现原理（去Segment，极致细粒度锁）： - 核心思想：CAS + synchronized on Node + volatile + Unsafe + LongAdder； - 关键字段： * transient volatile Node[] table：volatile保证数组引用可见性； * private transient volatile int sizeCtl：控制初始化、扩容状态（负数表示有线程在扩容，-1表示正在初始化，-N表示有N-1个线程参与扩容）； * Node：next为volatile，保证链表遍历可见性；value和hash也为volatile（注意：JDK8中Node.value是volatile的！这是与HashMap的关键区别）； - 初始化：首次put时，通过CAS将sizeCtl设为-1，成功者执行initTable()，失败者自旋等待； - put流程： 1. 计算hash = spread(key.hashCode())，定位tab[i]； 2. 若tab[i]为null，直接CAS设置新Node； 3. 若tab[i]为MOVED（即当前正在扩容），协助扩容（helpTransfer）； 4. 否则synchronized锁住tab[i]首节点（f = tab[i]），再遍历链表/红黑树插入； - 扩容（transfer）： * 单线程发起，通过sizeCtl协调多线程协作迁移； * 每个线程分配一段table区间（stride），迁移时先标记该桶为ForwardingNode（nextTable引用新表），再逐个迁移旧桶内节点； * ForwardingNode的find()方法会跳转到新表继续查找，保证扩容期间读操作不阻塞； - 链表转红黑树：当链表长度≥8且table.length≥64时，调用treeifyBin()；但需先获取该桶的synchronized锁，再判断是否满足条件，避免并发重复树化； - size统计：使用LongAdder（分段base + Cell[]数组），putSuccess后调用addCount(1L, binCount)，避免高并发下CAS争用；size()方法仅汇总base + cells中各值； - 读操作（get）：全程无锁，依赖volatile变量（table、Node.next、Node.value）和Unsafe.getObjectVolatile保证可见性；即使在扩容中，也能通过ForwardingNode无缝跳转。 - 代码示例（JDK8 ConcurrentHashMap核心片段伪代码）： // putVal关键逻辑节选 final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); // 高位参与hash，减少碰撞 int binCount = 0; for (Node[] tab = table;;) { Node f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // CAS初始化 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) { if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) { 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; } } } else if (f instanceof TreeBin) { // 红黑树分支... } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); // 触发树化（需持锁） break; } } } addCount(1L, binCount); // 更新计数器 return oldVal; } // 获取volatile Node（Unsafe实现） static final Node tabAt(Node[] tab, int i) { return (Node)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE); } // CAS设置Node static final boolean casTabAt(Node[] tab, int i, Node c, Node v) { return U.compareAndSwapObject(tab, ((long)i << ASHIFT) + ABASE, c, v); } - 扩展知识： * 为什么ConcurrentHashMap不允许null key/value？—— 因为get(null)无法区分“key不存在”和“key存在但value为null”，破坏语义一致性；且在并发场景下，null值会干扰CAS判断（如tabAt返回null可能是空桶，也可能是被删除节点）； * JDK9+进一步优化：引入VarHandle替代Unsafe（更安全、标准化的底层操作）；并增强Map接口默认方法的并发支持； * 对比其他线程安全Map：Collections.synchronizedMap()是全表锁，吞吐量低；Hashtable也是全表synchronized，且方法设计陈旧（如elements()返回Enumeration）；ConcurrentHashMap是唯一兼顾高性能与强一致性的工业级选择； * 实际面试中可延伸：如何实现一个简易版ConcurrentHashMap？（答：至少包含volatile table、CAS初始化、synchronized per bucket、volatile next/value、size用AtomicLong）； * JVM层面关联：volatile的内存语义对应lock前缀指令（x86）或内存屏障（如StoreLoad barrier），确保指令重排序受限；synchronized对应monitorenter/monitorexit字节码，底层基于ObjectMonitor（C++实现，含_waitSet/_entryList等队列）。以上内容覆盖了从现象到本质、从JDK版本演进到内存模型底层的完整知识链条，适用于深度技术面试考察。

26-2-28

全站热榜

创作者周榜