HashMap.put()在多线程下会丢数据，因其非原子操作且头插法导致链表节点被覆盖；Java 7扩容时头插法还可能引发死循环；ConcurrentHashMap通过volatile、CAS和分段锁保障线程安全，get()无需加锁但size()弱一致。
HashMap.put() 在多线程下为什么会丢数据
因为 put() 不是原子操作，多个线程同时写入同一个桶（bucket）时，链表头插法会导致节点丢失。比如线程 A 正在把新节点插入链表头部，线程 B 同时也做这事，B 的操作可能覆盖 A 的 next 指针，A 的节点就彻底“消失”了。
- 典型现象：
map.put("k1", "v1")执行了，但后续get("k1")返回null - 触发条件：多个线程往同一个 key（或 hash 冲突的 key）反复
put()，尤其在初始容量小、负载因子高时更易复现 - 不是“偶尔出错”，而是只要竞争发生，数据一致性就无法保证——这不是概率问题，是设计使然
resize() 过程中死循环是怎么产生的
Java 7 的 HashMap 扩容时用头插法迁移链表，多线程并发 resize 可能导致链表成环。一旦成环，后续 get() 或 size() 就会无限遍历，CPU 100%，线程卡死。
- 错误现象：
Thread.currentThread() is blocked in HashMap.get()，jstack 显示在getEntry()中死循环 - Java 8 改为尾插法，避免了成环，但
resize()本身仍非原子——多线程下仍可能丢数据、覆盖、甚至数组索引越界 - 注意：
ConcurrentHashMap的扩容是分段进行的，不会整体锁住整个 table，这是关键区别
用 Collections.synchronizedMap 包一层就够了吗
够用，但容易误以为“安全了”而忽略粒度问题。Collections.synchronizedMap() 只是对每个 public 方法加了 synchronized(this)，它保的是单个操作的原子性，不是复合操作。
- 典型陷阱：
if (!map.containsKey(key)) map.put(key, value);—— 这里containsKey()和put()是两次独立加锁操作，中间可能被其他线程插入相同 key - 性能影响：所有操作串行化，高并发下吞吐量断崖式下降，远不如
ConcurrentHashMap - 替代方案优先选
ConcurrentHashMap，除非你明确需要 synchronizedMap 的阻塞语义（比如配合 wait/notify）
ConcurrentHashMap 的 get() 为什么不需要加锁
因为它的 Node 数组用 volatile 声明，且读操作依赖 Unsafe.getObjectVolatile() 保证可见性；同时 Node 字段也是 final 或 volatile，避免指令重排导致读到半初始化对象。
立即学习“Java免费学习笔记（深入）”；
- 不加锁 ≠ 不同步：底层靠 volatile + CAS + 分段锁（Java 8 起是 CAS + synchronized on node）协同保障
- 注意：
size()和isEmpty()在 Java 8 中是弱一致性——可能反映“某个时刻”的近似值，不能用于强校验逻辑 - 如果真要强一致的 size，得用
mappingCount()（返回long），它比size()更准确，但仍不是实时精确值
真正难处理的不是“怎么选容器”，而是那些隐含的复合操作——比如先查再删、先算再存、批量更新时的边界检查。这些地方即使用了 ConcurrentHashMap，也得自己加锁或用 computeIfAbsent() 这类原子方法兜底。
