concurrenthashmap 的 get 不加锁也能安全，是因为 node 的 val 和 next 字段为 volatile，借助 jvm 内存模型的 happens-before 保证可见性，单次读取原子且无需锁；全程仅三次内存访问，遇扩容自动查新表。
ConcurrentHashMap 为什么 get 不加锁也能安全？
因为 Node 的关键字段都声明为 volatile：比如 val 和 next。只要一个线程写入了新值，其他线程读取时就能立刻看到最新结果——这是 JVM 内存模型的 happens-before 保证，不是靠锁，而是靠语义约束。
常见错误现象：有人误以为 “没加锁 = 可能读到中间状态”，但在 get 场景下，只要不涉及复合操作（比如先读再算再写），单次读取 volatile 字段就是原子且可见的。
-
get操作全程无锁，只做三次内存访问：定位数组索引 → 读首节点 → 遍历链表或红黑树（若存在） - 如果首节点是
ForwardingNode（hash = -1），说明正在扩容，get会直接去新表查，无缝切换 - 红黑树节点封装在
TreeBin中，其内部查找也用volatile保护结构字段，不依赖锁
put 是怎么避免竞争覆盖的？CAS + 自旋 + 细粒度锁
putVal 的核心不是“抢一把大锁”，而是分阶段控制：先用 CAS 尝试无锁写入空槽；失败则退到 synchronized 锁住单个桶（Node 首节点）；极端情况（如链表转树）才升级锁范围。
容易踩的坑：以为 “synchronized 锁的是整个 ConcurrentHashMap”，其实它只锁当前桶的头节点（f），其它桶完全不受影响。
- 首次插入空桶：调用
casTabAt(tab, i, null, new Node(...))，成功即退出 - 发现桶非空且未扩容：用
synchronized(f)锁住该Node，再遍历链表/树插入或更新 - 遇到
ForwardingNode（hash == -1）：说明有线程正在扩容，当前线程主动调用helpTransfer协助搬数据 - 不允许
nullkey/value：一上来就抛NullPointerException，这点和HashMap不同
扩容过程如何做到读写不阻塞？
扩容不是“停服重建”，而是渐进式迁移：新旧两张表并存，用 sizeCtl 控制状态，每个线程只负责搬自己分到的一小段（stride 默认 16 个桶），老表仍可读写，新表逐步填充。
性能影响：扩容期间 get 自动路由到新旧表，put 若命中已迁移的桶则直接写新表，否则先帮搬再写——所以并发越高，扩容越快，但单次 put 延迟可能略升。
- 触发条件：
addCount检测到元素数超过sizeCtl（≈ table.length × 0.75） - 初始扩容线程将
sizeCtl设为负数标记（如-2），后续线程通过 CAS 递增计数器加入协作 - 每个线程处理一个区间：从高位开始逐段扫描，搬完一段就更新
transferIndex，避免重复 - 搬完后，最后一个线程把
nextTable赋给table，并重置sizeCtl为新容量阈值
JDK 1.7 和 1.8 的并发模型差异在哪？
1.7 是“分段锁（Segment）”，1.8 是“桶级锁（synchronized on Node）+ CAS”，前者锁粒度固定（默认 16 段），后者动态适配实际冲突热点，更轻量、更灵活。
兼容性注意：1.7 的 concurrencyLevel 参数在 1.8 中仅保留用于向后兼容，实际不再划分 Segment，传参无效。
- 1.7：每个
Segment是ReentrantLock子类，锁住整个段，最多支持concurrencyLevel个线程并发写 - 1.8：彻底去掉
Segment，用Node[]+volatile+CAS+synchronized替代，锁只落在具体桶的头节点上 - 1.8 新增红黑树支持：当链表长度 ≥ 8 且数组长度 ≥ 64，自动树化，查找从 O(n) 降到 O(log n)
- 1.8 的
spread方法对 hash 做二次扰动（高16位异或低16位），比 1.7 的两次哈希更简洁高效
真正难啃的是扩容协作逻辑和各种状态码（如 MOVED、TREEBIN、RESERVED）的边界判断——这些不是靠死记，而是在调试多线程压测时，盯着 sizeCtl 和 nextTable 的变化才能真正吃透。
