ConcurrentHashMap通过分段锁（1.7）或CAS+synchronized单节点锁（1.8+）实现细粒度并发控制，读操作无锁，写操作仅锁冲突桶；Hashtable则全局同步，读写互斥。
ConcurrentHashMap 的分段锁和 CAS 是怎么工作的
ConcurrentHashMap 不是靠整个 Map 加锁来保证线程安全的，它把数据分成多个 Segment（1.7）或用 Node 数组 + volatile + CAS（1.8+），锁只落在具体桶（bucket）上。这意味着读操作几乎无锁，写操作也只锁住冲突的那一小片区域。
常见错误是以为 ConcurrentHashMap 对所有操作都“完全无锁”——其实 putIfAbsent、computeIfAbsent 这类复合操作仍需加锁或重试，尤其在高并发下可能因 CAS 失败而自旋多次。
- 1.7 版本：默认 16 个
Segment，锁粒度 ≈ 数组长度 / 16；可通过构造参数concurrencyLevel调整，但只是估算值，不是硬限制 - 1.8+ 版本：去掉
Segment，改用synchronized锁单个Node链表头或红黑树根，配合Unsafe.compareAndSwapObject做初始化和扩容控制 - 扩容时采用“多线程协助扩容”机制：第一个触发扩容的线程建新表，后续线程若发现正在扩容，会主动帮着迁移部分桶，而不是排队等待
Hashtable 为什么一写就卡住所有读
Hashtable 所有 public 方法都用 synchronized 修饰，等价于对整个对象加锁。哪怕你只 put 一个 key，其他线程想 get 任意 key 都得等——锁粒度是整个实例，不是某个桶，也不是某个 key。
典型误用场景：用 Hashtable 存配置项，但频繁调用 get，结果发现 QPS 上不去，CPU 却不高，其实是大量线程在锁池里阻塞等待。
立即学习“Java免费学习笔记（深入）”；
-
containsKey和get都要抢同一把锁，无法并发读 - 迭代器
Enumeration是 fail-fast 的，且遍历时锁住整个表，期间任何写操作都会被阻塞 - 不支持
nullkey 或 value，抛NullPointerException，这点和ConcurrentHashMap一致，但错误时机不同：前者在 put 时就报，后者允许 null value（JDK 1.8+）
什么时候该选 ConcurrentHashMap 而不是 Hashtable
除非你在维护一段 JDK 1.4 的老代码，否则没有理由选 Hashtable。它的设计目标是“线程安全”，但实现方式早已过时，性能差、扩展性弱、API 陈旧。
真实项目中，选 ConcurrentHashMap 的核心依据是：读多写少 + 需要高吞吐 + 不能接受全局阻塞。
- Web 应用缓存用户 session ID → 用
ConcurrentHashMap，因为 get 极频繁，put 较少且分散 - 统计接口调用量（按 path 分桶计数）→ 用
ConcurrentHashMap，每个 path 的计数互不干扰 - 需要强一致性遍历（比如 dump 全量状态）→
ConcurrentHashMap的entrySet().iterator()不保证反映某一时刻快照，此时得自己加外部锁或用CopyOnWriteArrayList配合
ConcurrentHashMap 的 size() 和 isEmpty() 为什么不准
size() 在 1.8+ 中返回的是一个估算值：它累加每个 bin 的 baseCount，再结合 counterCells 数组的增量，但不加锁也不阻塞。所以并发修改时，可能漏计或重复计数。
这不是 bug，是设计取舍——为了不牺牲并发性能，放弃绝对精确的大小统计。
-
isEmpty()同样是估算：只检查baseCount == 0且所有 bin 都为空，但中间可能有线程刚插入又还没更新计数 - 如果业务逻辑依赖“是否为空”做分支（比如空则初始化），别直接用
isEmpty()，应改用computeIfAbsent或先get再判断 -
size()在扩容过程中可能短暂翻倍或归零，日志里看到 “size=2000, then size=0, then size=4000” 属正常现象
真正难处理的从来不是“怎么选容器”，而是当你的业务逻辑隐含了对容器行为的强假设（比如认为 size() 可靠、或 put 后立刻能被所有线程 get 到），这些地方最容易出竞态问题，而且很难复现。
