concurrenthashmap线程安全靠分段锁（jdk7）或cas+synchronized单节点锁（jdk8+），get()无锁，put()仅锁桶头，size()非o(1)且有误差，迭代器弱一致性，foreach()不支持遍历时修改，computeifabsent()可能重复初始化，扩容时get()可能读到旧值。
ConcurrentHashMap 的线程安全不是靠 synchronized 全局锁
它用的是分段锁（JDK 7）或 CAS + synchronized 锁单个 Node（JDK 8+），只锁哈希桶链表/红黑树的头节点，而不是整个 Map。这意味着多个线程可以同时读写不同桶的数据，吞吐量远高于 Hashtable 或 Collections.synchronizedMap()。
常见误解是“它内部全加了锁”，实际在 JDK 8 中：get() 完全无锁（依赖 volatile 语义），put() 只在必要时对桶首节点加 synchronized，且锁粒度极小。
-
size()不是 O(1)，而是遍历所有CounterCell累加，可能有短暂误差（最终一致） -
containsKey()和get()行为一致，都无锁、不阻塞 - 迭代器弱一致性：不抛
ConcurrentModificationException，但可能漏掉或重复看到刚插入/删除的元素
为什么不能用 forEach() 替代 for-loop 遍历 ConcurrentHashMap
forEach() 是 ConcurrentHashMap 自带的并行遍历方法，底层调用 Traverser 分段扫描，但它的行为和传统 for-each 循环（即 entrySet().iterator()）有本质区别：
-
entrySet().iterator()返回的是弱一致性迭代器，遍历时允许并发修改，但不保证看到最新状态 -
forEach(BiConsumer)在遍历中若其他线程修改了正在访问的桶，该次遍历仍会继续，但不会反映那些修改；它不阻塞也不重试 - 更关键的是：
forEach()无法在遍历中安全地执行remove()或computeIfAbsent()—— 这些操作会引发IllegalStateException或不可预期结果
真正需要边遍历边更新时，应改用 replaceAll()、computeIfPresent() 等原子方法，或先收集 key 再批量处理。
立即学习“Java免费学习笔记（深入）”；
computeIfAbsent() 在高并发下可能重复初始化
computeIfAbsent() 声称“只计算一次”，但前提是传入的 mappingFunction 是幂等的。它底层逻辑是：先 get()，没命中再加锁、再次检查、再调用函数。两次检查之间存在窗口，若 mappingFunction 创建对象开销大或有副作用，就可能被多个线程同时触发。
典型错误场景：
map.computeIfAbsent(key, k -> new ExpensiveObject(k)); // 可能创建多个实例
解决方式：
- 确保 mappingFunction 本身轻量且无副作用
- 若必须延迟初始化重型资源，改用双重检查 +
putIfAbsent()组合 - JDK 9+ 提供了
computeIfAbsent(key, mappingFunction)的替代思路：用ConcurrentHashMap配合FutureTask缓存初始化任务
扩容时 get() 为什么不会阻塞，但可能看到旧值
ConcurrentHashMap 扩容是渐进式迁移（JDK 8 中通过 transfer() 方法），由首个触发扩容的线程启动，后续 put/get 线程协助迁移。关键点在于：get() 遇到正在迁移的桶（即 ForwardingNode），会直接跳转到新表查询。
但这个过程不是原子切换：
- 旧表中部分桶已迁走，部分还没动
- 如果一个 key 在旧表中尚未迁移，
get()会从旧表读到旧值；若此时新表已写入新值，旧值就是“过期”的 - 这种不一致仅存在于迁移窗口期（通常很短），属于最终一致性范畴，不是 bug
所以不要依赖 get() 立即看到 put() 后的最新值——这和 volatile 字段类似，只能保证可见性，不保证实时性。
