HashMap非线程安全，多线程写入易致ConcurrentModificationException、数据丢失或死循环；ConcurrentHashMap通过CAS、细粒度锁和弱一致性迭代器实现高并发安全，但不支持null键值。
HashMap不是线程安全的，多线程写入会出问题
直接在多线程环境下对HashMap执行put操作，极大概率触发ConcurrentModificationException或导致数据丢失、死循环（JDK 7 中的头插法扩容可能引发链表成环）。这不是偶发 bug，而是设计使然——HashMap所有方法都不加锁，也不做任何同步防护。
常见误用场景包括：Web 应用中将HashMap作为类成员变量，在多个请求线程中反复put；或在并行流（parallelStream()）里修改共享HashMap。
- 别指望“只读不写”就安全：即使初始化后只读，若构造过程中有并发写入（如双检锁单例里未正确发布），仍可能看到部分初始化状态
-
Collections.synchronizedMap(new HashMap())能加锁，但仅保证单个操作原子性，ifAbsent-then-put这类复合操作仍需额外同步
ConcurrentHashMap通过分段锁和CAS保障高并发读写
ConcurrentHashMap在 JDK 8+ 彻底重构：放弃分段锁（Segment），改用Node数组 + 链表/红黑树 + Unsafe.compareAndSwap + 细粒度synchronized（仅锁链表头或红黑树根节点）。读操作完全无锁，写操作只锁局部桶（bin），吞吐量远高于全局同步的Hashtable或Collections.synchronizedMap。
它不支持null作为 key 或 value（抛NullPointerException），这点和HashMap不同，是刻意为之——避免在并发判断中因null歧义引发逻辑错误。
立即学习“Java免费学习笔记（深入）”；
-
computeIfAbsent、merge等方法是原子的，适合缓存加载场景，比如：cache.computeIfAbsent(key, k -> loadFromDB(k));
- 迭代器弱一致性：遍历时允许其他线程修改，不会抛
ConcurrentModificationException，但可能漏掉新加入的元素，也不会反映已删除元素——这正是为性能做的取舍
遍历方式不同，结果语义也不同
HashMap的entrySet().iterator()是强一致快照，遍历时若结构被修改（如扩容、rehash），立刻抛异常；而ConcurrentHashMap的迭代器不阻塞写入，也不保证看到所有变更。
更关键的是：二者对for-each循环中调用remove的行为处理完全不同。
-
HashMap：在增强 for 循环中调用map.remove(key)会触发ConcurrentModificationException -
ConcurrentHashMap：同样写法不会抛异常，但该remove操作本身不参与当前迭代逻辑，且不能保证移除成功（例如另一线程刚插入同 key） - 安全遍历并删除应统一用
replaceAll、compute系列，或显式使用Iterator.remove()（ConcurrentHashMap支持）
初始容量与扩容策略影响实际并发表现
ConcurrentHashMap构造时传入的initialCapacity会被自动向上取整为 2 的幂，并用于计算默认并发级别（JDK 8 后该参数仅作参考，实际由内部sizeCtl控制）；而HashMap的initialCapacity直接影响首次扩容时机。
如果预估写入量大但并发线程少，盲目设高initialCapacity会导致内存浪费；反之，低容量 + 高并发会频繁触发扩容，而ConcurrentHashMap扩容是渐进式、多线程协作的，虽不阻塞读，但会增加 CPU 开销。
- 推荐做法：根据预期总键值对数量 ÷ 并发线程数，再乘以 1.5~2 倍作为
initialCapacity - 避免使用
new ConcurrentHashMap(16, 0.75f, 1)这种过时写法（JDK 8+ 第三个参数已被忽略） -
HashMap的loadFactor调整会影响扩容频率，但ConcurrentHashMap没有公开暴露该参数，其装载因子固定为 0.75
HashMap——这时用ConcurrentHashMap反而增加不必要的开销。真正需要关注的，是那些被多个线程反复修改的共享状态容器。 
