HashMap 多线程不安全，主因是 put、resize、remove 等操作无同步控制，易致数据丢失、死循环（JDK7头插法成环）、size/modCount 非原子更新；应依场景选 ConcurrentHashMap、synchronizedMap 或不可变包装。
HashMap 在多线程环境下不是线程安全的，核心原因在于其内部结构修改操作（如 put、resize、remove）没有同步控制，多个线程同时触发这些操作时，可能引发数据丢失、死循环、数组越界或不一致状态等问题。
扩容时的并发问题：链表成环导致死循环
在 JDK 7 中，HashMap 使用头插法将原链表节点迁移到新数组。当两个线程同时检测到需要扩容并进入 transfer() 方法时，可能因执行顺序交错，使某个链表节点的 next 指针指向自身或形成环形链表。后续调用 get() 遍历时会无限循环，CPU 占用飙升。
JDK 8 改为尾插法，避免了环形链表，但扩容过程仍非原子操作，多个线程并发扩容仍可能导致部分节点丢失或重复插入。
put 操作的竞态条件：数据覆盖与丢失
多个线程同时对同一个桶（bucket）执行 put，可能出现以下情况：
立即学习“Java免费学习笔记（深入）”；
- 线程 A 和 B 同时发现 key 不存在，都准备插入新节点；
- A 先完成插入，B 后写入，直接覆盖 A 的值（未加锁，无 CAS 或 volatile 保障）；
- 若涉及树化或链表遍历，还可能因中间状态不一致，跳过已有节点，造成“假性不存在”而重复插入。
size 和 modCount 的非原子更新
size 字段未用 volatile 修饰，也未同步更新，多线程读写时可能看到过期值；modCount 用于快速失败机制（fail-fast），但并发修改下它无法准确反映结构变更次数，导致 ConcurrentModificationException 可能不抛出，也可能误抛，行为不可预测。
如何安全地在多线程中使用类似 HashMap 的功能
根据场景选择合适方案：
- 读多写少：用
ConcurrentHashMap（JDK 8 使用 CAS + synchronized 分段锁优化，性能远高于Hashtable）； - 写操作有严格顺序要求：用
Collections.synchronizedMap(new HashMap())，但注意迭代仍需手动同步； - 仅初始化后只读：可用
Map.copyOf()（JDK 10+）或UnmodifiableMap包装； - 需强一致性且并发不高：用
Hashtable（已基本被ConcurrentHashMap取代）。
不复杂但容易忽略：即使只用 get，若其他线程正在 put 或扩容，仍可能读到不一致的中间状态——所以“只读”必须是真正意义上的不可变。
