- 正确答案：HashTable 是线程安全的，HashMap 不是线程安全的；但“线程安全”是相对且有代价的——HashTable 通过方法级 synchronized 实现同步，粒度粗、性能差、已基本被弃用；现代 Java 中更推荐使用 ConcurrentHashMap（JDK 7/8 优化后高性能、分段/细粒度锁 + CAS + volatile），或根据场景选择 Collections.synchronizedMap（简单包装，全表锁）、CopyOnWriteHashMap（仅适用于读多写极少且允许弱一致性）等。 - 解答思路：首先明确“线程安全”的定义：在多线程并发访问下，无需外部同步即可保证数据结构内部状态一致、行为符合预期（如不会出现 NullPointerException、size 不一致、无限循环链表等）。然后对比两者实现： • HashTable 的所有 public 方法（put、get、remove、size 等）均用 synchronized 修饰，锁的是 this 对象，即每次操作独占整个哈希表，导致高并发下严重串行化； • HashMap 完全无同步机制，多线程 put 可能触发扩容时形成环形链表（JDK 7 中典型 bug，导致 get 死循环），JDK 8 虽改用红黑树+尾插法避免环形链表，但仍存在数据覆盖、丢失更新、size 计算错误等竞态问题。最后指出：线程安全 ≠ 推荐使用；应从并发模型（读写比、一致性要求、实时性）、扩展性、GC 压力等维度评估替代方案。 - 深度知识讲解：【1】HashTable 底层原理（JDK 8 源码视角）：继承 Dictionary（抽象类，已废弃），内部数组 Entry[] table，Entry 是 synchronized 的静态内部类（但实际未用到其同步性），put 方法签名： public synchronized V put(K key, V value) { ... } 扩容 rehash() 也全程加锁，resize 后需遍历旧表逐个 rehash 到新表，期间整个表不可读写。缺陷：锁粒度为 whole-table，无法并发读；不支持 null 键/值（key == null 会直接抛 NullPointerException），限制 API 表达力。【2】HashMap 非线程安全的根本原因（以 JDK 8 为例）： • putVal() 中的 CAS + synchronized 混合机制仅保护单个桶（bin），但全局 size 属性是普通 int，多线程 increment 会丢失更新（非原子）； • resize() 过程中 transfer() 方法若被多个线程同时触发，可能因节点迁移顺序不同导致部分节点被遗漏或重复链接； • modCount（fail-fast 机制）非 volatile，多线程修改可能导致迭代器无法及时感知结构性变更，或误报 ConcurrentModificationException。【3】ConcurrentHashMap 的演进与设计哲学： • JDK 7：采用 Segment 数组 + HashEntry 分段锁（默认 16 段），每段独立加锁，理论上支持 16 线程并发写；但 Segment 本身是可重入锁，仍存在锁竞争和内存占用大问题。 • JDK 8 彻底重构：取消 Segment，改用 Node 数组 + synchronized(CAS) 控制单个桶头结点 + volatile + Unsafe.compareAndSwapInt/Long； – 插入时：先无锁尝试 CAS 插入头结点，失败则 synchronized 锁住该桶头节点（锁粒度=单个桶）； – 扩容时：支持多线程协作扩容（transferIndex、sizeCtl 协同控制），每个线程负责迁移若干 bin，通过 nextTable 和 forwardingNode 标记迁移状态，实现无锁读 + 协作写； – 查找 get()：全程无锁，依赖 volatile 语义读取 table、next、val 字段（Node 的 val 和 next 均为 volatile），保证可见性； – size()：不再维护全局变量，而是通过 baseCount + CounterCell[] 数组（类似 LongAdder）分散计数，避免 write-contention。【4】其他替代结构对比： • Collections.synchronizedMap(new HashMap<>())：本质是装饰器模式，所有方法套一层 synchronized(this)，仍是全表锁，性能 ≈ HashTable，但支持 null； • CopyOnWriteArrayList 有对应 Map 变体？注意：JDK **没有** CopyOnWriteHashMap！因为 COW 适用于 list（索引访问+写少），而 Map 的 hash 查找依赖数组结构，每次写都 copy 整个 table（O(n) 时间 + O(n) 内存），且无法保证 key 的哈希分布连续性，工程上不可行；若真需 COW 语义，可用 Collections.unmodifiableMap + 手动重建，但需业务层协调； • 更高阶选型： – 若需强一致性 + 分布式：考虑 Redis + Lua 或 etcd + 事务； – 若需高性能本地缓存 + 过期/淘汰：Caffeine（基于 Window TinyLfu + Segmented Clock Probing，支持异步刷新、权重、大小限制）； – 若需实时统计/聚合：LongAdder / DoubleAdder（非 Map 结构，但解决计数并发问题）； – 若需并发有序映射：ConcurrentSkipListMap（基于跳表，支持 NavigableMap 接口，log(n) 并发查找/插入，但比 CHM 慢约 3–5 倍）。 - 伪代码示意 ConcurrentHashMap JDK 8 putVal 关键逻辑： ``` 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(); // 懒初始化，CAS 设置 sizeCtl 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) { // 红黑树分支 Node p; binCount = 2; if ((p = ((TreeBin)f).putTreeVal(hash, key, value)) != null) { oldVal = p.val; if (!onlyIfAbsent) p.val = value; } } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) // 链表长度≥8 且 table≥64 才树化 treeifyBin(tab, i); break; } } } addCount(1L, binCount); // 更新计数（baseCount + CounterCell） return oldVal; } ``` - 总结建议： • 单线程 or 低并发：用 HashMap，零开销； • 明确需要线程安全且兼容老代码：优先用 ConcurrentHashMap，而非 HashTable； • 高读低写 + 允许短暂不一致（如配置缓存）：ConcurrentHashMap + 自定义过期策略； • 极高并发 + 复杂查询（范围、排序）：评估 ConcurrentSkipListMap 或外置缓存； • 所有场景下，避免在构造函数/静态块中直接 new HashTable() —— 它是历史包袱，JavaDoc 明确标注 "@deprecated This class is obsolete"。

广州小厂技术面

全站热榜

创作者周榜