HashMap非线程安全，高并发下会导致数据不一致和结构性破坏；ConcurrentHashMap通过分段锁（JDK7）或CAS+synchronized单桶锁（JDK8+）实现高效并发；读写分离场景可选ReadWriteLock，但需注意粒度与性能。
HashMap 本身不处理高并发下的读写锁冲突——它压根没有锁机制，也不是线程安全的。
为什么 HashMap 不能用于高并发读写
它内部没有同步控制，多线程同时读写会直接引发两类严重问题：
- 数据不一致：比如两个线程同时 put 相同 key，其中一个值可能被静默覆盖，且无任何提示；
- 结构性破坏：JDK 7 中并发扩容可能导致链表成环，触发 get() 无限循环，CPU 瞬间拉满；JDK 8 虽缓解但未根除，仍可能丢失更新或迭代器抛 ConcurrentModificationException。
真正能处理读写冲突的是 ConcurrentHashMap
它不是给 HashMap “加读写锁”，而是用更精细的并发策略替代了传统锁：
- JDK 1.7：用 Segment 数组分段，每段独立加锁，写操作只锁对应段，读完全无锁；
- JDK 1.8+：取消 Segment，改用 Node 数组 + CAS + synchronized 锁单个桶的头节点，读操作零同步，写仅阻塞同桶的其他写线程；
- 迭代器是弱一致的，不抛 ConcurrentModificationException，允许遍历时并发修改。
读写分离场景可选 ReadWriteLock 封装普通 Map
若业务明确“读远多于写”且需强一致性（如本地缓存加载），可用 ReentrantReadWriteLock 手动控制：
立即学习“Java免费学习笔记（深入）”；
- 读操作获取读锁（允许多个线程并发读）；
- 写操作获取写锁（独占，阻塞所有读与写）；
- 务必配合双重检查（Double-Check），避免重复加载；
- 注意：锁粒度是整个 map，性能不如 ConcurrentHashMap，仅适合写极少、读极重、且需要精确状态的场景。
关键避坑提醒
别试图“修复” HashMap 的并发问题：
- 不要用 Collections.synchronizedMap()——它只是给每个方法加 synchronized，等价于全局锁，高并发下吞吐量骤降；
- 不要在 computeIfAbsent 或 putIfAbsent 里执行耗时操作（如 DB 查询、HTTP 调用），会卡住整个桶；
- 不要依赖 size()，它要遍历所有段，结果不准还慢；改用 mappingCount()；
- 别把 ConcurrentHashMap 当作配置中心或事件总线——它不支持监听、版本控制或原子批量更新。
