vector虽线程安全但性能差，仅适用于低并发场景；concurrenthashmap采用cas与细粒度锁，适合高并发读写，二者迭代器行为、扩容机制及适用场景截然不同。
Vector 是线程安全的，但别真拿来当并发容器用
Vector 的每个方法都加了 synchronized，看起来“天然线程安全”，实际是把所有操作串行化。哪怕只是读一个元素，也要锁住整个对象——高并发下吞吐量断崖式下跌，还容易引发线程争抢和上下文切换开销。
常见错误现象：ConcurrentModificationException 依然会出现（比如遍历时另一个线程调用 add()），因为迭代器不是 fail-safe 的；或者压测时 CPU 使用率低、QPS 却上不去，就是锁粒度太粗拖累了。
- 只适合单线程或极低并发场景（比如初始化配置列表后不再修改）
- 不要在 for-each 循环里修改 Vector，会触发
ConcurrentModificationException - 替代方案不是“换一个同步容器”，而是看是否真的需要同步——多数时候该用
ArrayList+ 显式锁 / 不可变集合 / 或直接上CopyOnWriteArrayList
ConcurrentHashMap 的线程安全是分段实现的，不是靠 synchronized
Java 8 之后 ConcurrentHashMap 已经不用分段锁（Segment），改用 CAS + synchronized 锁单个桶（Node），写操作只锁冲突的链表头或红黑树根节点，读操作完全无锁。这是它比 Vector 高效的根本原因。
使用场景：缓存、计数器、高频读+低频写的共享状态映射。但注意它不支持 contains() 这种全局扫描操作（已废弃），也不保证实时强一致性——比如 size() 可能返回估算值，isEmpty() 是可靠的。
立即学习“Java免费学习笔记（深入）”；
-
put()和get()是线程安全的，但复合操作如“先 get 再 put”不是原子的，得用computeIfAbsent()或merge() - 不能存
nullkey 或 value（会抛NullPointerException），这点和HashMap一致 - 迭代过程允许其他线程修改，所以遍历结果可能不反映某一时刻的快照，但不会抛异常
Vector 和 ConcurrentHashMap 的迭代器行为完全不同
Vector 的 iterator() 返回的是 fail-fast 迭代器，只要结构被修改（哪怕只是别的线程 add 一个元素），下次调用 next() 就抛 ConcurrentModificationException；而 ConcurrentHashMap 的迭代器是弱一致的（weakly consistent），不抛异常，也不保证看到所有更新，但能确保不漏掉正在遍历的节点。
这意味着：用 Vector 做共享列表并多线程遍历，基本等于给自己埋雷；而 ConcurrentHashMap 在遍历时被修改，程序不会崩，但业务逻辑得接受“看到的数据可能滞后”。
- Vector 遍历出错时，有人会加
synchronized块包住整个 for 循环——这反而让并发退化成串行 - ConcurrentHashMap 中想“安全地遍历+处理”，应避免依赖顺序或总数，必要时用
mappingCount()替代size() - 如果业务要求遍历时绝对不可变，就别用它们，改用
ImmutableList或复制一份再处理
别忽略初始化参数对 ConcurrentHashMap 性能的影响
ConcurrentHashMap 构造时传的 initialCapacity 不是桶数量，而是预估的键值对总数；内部会向上取整到最近的 2 的幂，再除以默认并发级别（Java 8 是 16）来算初始桶数。设得太小会导致频繁扩容（rehash），太大又浪费内存。
常见错误：直接写 new ConcurrentHashMap()，然后往里塞几万条数据——初期性能尚可，但一旦触发扩容，所有线程都要参与迁移，卡顿明显；或者按 HashMap 经验设 initialCapacity = 1000，结果实际分配了 2048 个桶，但并发写只集中在前几个，其余闲置。
- 预估容量时，按「峰值并发写入量 × 平均每个桶承载条数（约 2–8）」来倒推
- 如果写多读少且 key 分布不均，考虑重写
hashCode()让散列更均匀 - Java 9+ 支持
new ConcurrentHashMap(initialCapacity, loadFactor)，但loadFactor仅影响扩容阈值，不影响并发度
