hashmap在多线程环境下会因并发扩容导致环形链表而引发死循环（jdk1.7），jdk1.8虽修复环形问题，但仍存在数据丢失、size不准等竞态问题；正确做法是使用concurrenthashmap，其读操作无锁、写操作仅锁单个桶，并提供原子复合方法。
Java 中 HashMap 本身不支持高并发读写，直接在多线程环境下使用会导致数据错乱、死循环甚至 JVM 崩溃。它不是线程安全的，所以不能靠加锁或调优来“修复”它的并发问题——正确做法是换用真正为并发设计的替代方案，其中 ConcurrentHashMap 是最常用、最推荐的选择。
为什么 HashMap 在并发下会出问题
HashMap 的扩容机制（尤其是 JDK 1.7）在多线程同时触发时，可能形成环形链表，导致 get() 死循环；JDK 1.8 虽修复了环形问题，但依然存在数据覆盖、丢失更新、size 不准确等竞态行为。它没有内置同步控制，任何看似简单的 put() 或 get() 都可能因指令重排、可见性缺失而失效。
ConcurrentHashMap 如何解决读写瓶颈
它通过以下设计大幅降低锁竞争：
- 读操作完全无锁：get()、containsKey() 等依赖 volatile 和 Unsafe 的内存语义，不阻塞任何线程
- 写操作只锁单个桶（bin）：JDK 8+ 使用 CAS 尝试插入，失败后才对对应链表头或红黑树根节点加 synchronized 锁，不影响其他桶的读写
- 迭代器弱一致性：遍历时不抛 ConcurrentModificationException，允许并发修改，适合监控、日志等容忍短暂延迟的场景
- 原子复合操作丰富：如 computeIfAbsent()、replace(K, V, V)、putIfAbsent()，避免手动“先查后put”带来的竞态
哪些情况不该硬扛 HashMap 并发
以下做法看似能用，实则隐患明显：
- 用 synchronized 包裹 HashMap 操作：全局锁让所有线程排队，吞吐量断崖式下降
- 用 Collections.synchronizedMap()：本质也是全表锁，且遍历时必须手动同步 entrySet().iterator()
- 自己用 ReentrantLock + HashMap：易漏锁、难维护，绝大多数需求已被 ConcurrentHashMap 的 compute* 方法覆盖
- 盲目调大 initialCapacity 或 concurrencyLevel：后者在 JDK 8+ 已被忽略，前者只影响初始数组大小，不提升并发能力
实际使用建议
直接替换，注意三点：
- 初始化时用
new ConcurrentHashMap()，无需传参；若预估容量较大，可传 initialCapacity，但不必纠结 concurrencyLevel - 避免在 computeIfAbsent() 或 putIfAbsent() 的 lambda 中执行 I/O、数据库查询等耗时操作，否则会阻塞整个桶
- 不要依赖 keySet() / values() 返回集合的实时性——它们是快照视图，后续修改不会自动反映
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
