hashmap非线程安全，当一个线程执行get读取时，另一线程触发put导致扩容，可能引发无限循环、数据丢失或程序假死，行为完全未定义。
hashmap非线程安全，当一个线程执行get读取时，另一线程触发put导致扩容，可能引发无限循环、数据丢失或程序假死，行为完全未定义。
在Java中，HashMap 是典型的非线程安全集合类。其内部采用数组+链表（JDK 8起为数组+链表/红黑树）结构，而扩容（resize）操作涉及整个哈希桶数组的重建与元素重哈希迁移。关键问题在于：该过程并非原子操作，且未加任何同步保护。
当线程A执行 get(key) 时，它会定位到对应桶位置，并遍历链表查找节点；与此同时，线程B执行 put(k, v) 导致容量不足，触发 resize() —— 此时会新建更大数组，并将原数组中每个桶的链表头插法逐个迁移到新数组（JDK 7及之前）。正是这个“头插法”在多线程下埋下致命隐患：
// JDK 7 resize 中的典型迁移片段（简化）
Entry<k> next;
do {
next = e.next; // 保存下一个节点
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i]; // 头插：e 指向新桶头
newTable[i] = e; // 新桶头更新为 e
e = next;
} while (e != null);</k>
若两个线程并发执行该逻辑，可能使链表节点形成环形引用（如 A→B→A）。此时线程A在后续 get() 遍历时将陷入死循环，CPU占用飙升，永不返回结果——这正是“无限循环”的根本原因。
⚠️ 注意：JDK 8已改为尾插法，避免了环形链表，但仍不保证线程安全：并发resize仍可能导致数据覆盖、丢失、size计算错误，甚至
get()返回null（本应存在）或旧值（本应更新）。所有行为均属 undefined behavior（未定义行为） —— 不可预测、不可重现、不可依赖。
✅ 正确解决方案：
- 读多写少 → 使用
Collections.synchronizedMap(new HashMap())（全局锁，简单但吞吐低）； - 高并发读写 → 使用
ConcurrentHashMap（JDK 8+ 基于CAS+synchronized分段控制，高性能且语义明确）； - 纯读场景 → 若初始化后不再修改，可用
Collections.unmodifiableMap()包装。
总之，永远不要在多线程环境中直接共享可变的 HashMap 实例。线程安全不是“偶尔出错”，而是“任何时候都可能以任意方式崩溃”。
