ConcurrentHashMap 1.7 使用 Segment 分段锁是为了提升并发写入性能，将哈希表划分为默认16个独立加锁的Segment，使不同Segment上的线程可并行put；但key定位需两次hash，get无锁依赖volatile保证可见性，size()等操作需遍历全部Segment且可能重试，concurrencyLevel构造后不可变，向上取整为2的幂，Segment数量上限硬编码为1。
ConcurrentHashMap 1.7 为什么用 Segment 分段锁？
因为直接给整个哈希表加锁（像 HashTable 那样）会把所有线程堵成一列，而 JDK 1.7 想让“不碰同一块数据”的线程能真正并行写入——Segment 就是那块被独立加锁的数据单元。
每个 Segment 本质是一个小型 HashEntry[] 数组 + ReentrantLock，默认 16 个，意味着最多 16 个线程可同时在不同 Segment 上执行 put；但只要两个线程的 key 落到同一个 Segment，就会排队等锁。
- 定位 key 需两次 hash：
hash(key)→ 算出 Segment 下标；再用部分 hash 值 → 算出该 Segment 内部数组下标 -
get操作全程无锁，只靠volatile保证可见性，但可能读到旧值（弱一致性） -
size()和containsValue()必须遍历全部 Segment 并尝试加锁，可能阻塞或重试多次，性能差且结果未必实时
Segment 数量能动态调整吗？
不能。并发级别（concurrencyLevel）在构造时就决定了 segments 数组长度，之后固定不变；扩容只发生在单个 Segment 内部（即它的 HashEntry[] 数组），不会改变 Segment 总数。
- 传入
concurrencyLevel = 17，实际会向上取整为 32（最近的 2 的幂），不是“刚好 17 个锁” - 设得太小（如 2）→ 锁竞争激烈，退化成接近
HashTable性能 - 设得太大（如 65536）→ 内存占用高、初始化慢，且多数 Segment 长期空闲，无实际并发收益
Segment 里的 HashEntry 为什么用 volatile 修饰 next 和 value？
因为 get 不加锁，必须靠 volatile 保证其他线程对链表结构和值的修改能被立即看到；否则可能读到 null 或过期 value，甚至因指令重排序导致链表断裂。
-
HashEntry的key和hash是 final，天然安全；next和value是 volatile，构成“安全发布”链路 - 但注意：volatile 不保证复合操作原子性，比如
value++仍需额外同步 - 链表头插入是唯一写法（避免 tail 竞争），所以
next的 volatile 能覆盖大多数可见性场景
和 JDK 1.8 的 ConcurrentHashMap 相比，1.7 的 Segment 设计有哪些硬伤？
Segment 是一个权衡产物，它解决了全表锁问题，但也带来了结构性瓶颈：
- 两次 hash 计算开销比 1.8 的一次 hash 高；定位路径更长，CPU cache 友好度差
- Segment 数量上限硬编码为
1 ，无法支撑超大规模并发写入场景 - 扩容是单 Segment 串行进行，无法多线程协作迁移，扩容期间该 Segment 完全阻塞
- 链表无树化机制，当某个 Segment 内哈希冲突严重时，查询退化为 O(n)，且无法缓解
这些限制正是 JDK 1.8 彻底移除 Segment、改用 CAS + synchronized 锁单个桶（bin）的根本原因——粒度更细、结构更扁平、扩容可并行，但代价是代码逻辑复杂度大幅上升。
