ConcurrentHashMap线程安全但需按设计使用：读操作get等无锁且弱一致；写操作须用putIfAbsent等原子方法；初始化容量应预估并设为2的幂次；遍历接受弱一致性。
ConcurrentHashMap 本身线程安全，但高效读写不靠“加锁兜底”，而靠用对方法、设对参数、理解行为边界。它不是万能保险箱，而是需要按设计逻辑使用的高性能并发容器。
读操作直接 get，千万别加锁
get() 是无锁操作，依赖 volatile 字段和内存屏障保证可见性，性能几乎与 HashMap 持平。在缓存查询、配置读取等读多写少场景中，map.get(key) 就是最优解。
- 加 synchronized 或 ReentrantLock 会让所有读请求排队，吞吐量断崖式下跌
- containsKey、isEmpty 等读方法也无需外部同步
- 即使写操作正在发生，get 仍能返回某个时刻的一致快照（弱一致性）
写操作必须用原子方法，禁用 if-put 这类组合逻辑
像 if (!map.containsKey(k)) map.put(k, v) 看似合理，实则是竞态高发区：两个线程同时判定 key 不存在，接着都执行 put，后写覆盖前写。
- putIfAbsent(k, v)：key 不存在才插入，一次 CAS 完成
- computeIfAbsent(k, f)：key 不存在时调用函数生成值，函数只被一个线程执行（适合查库加载缓存）
- merge(k, v, (old, new) -> old + new)：安全累加，如计数器自增
- replace(k, oldValue, newValue)：带旧值校验的更新，防止误覆盖
初始化容量要预估并设为 2 的幂次
默认初始容量是 16，若实际要存百万级键值对，运行时频繁扩容会触发协作迁移，带来 CPU 峰值、GC 压力甚至短暂卡顿。
立即学习“Java免费学习笔记（深入）”；
- 预估总键数（例如 180 万），向上取整到最近的 2 的幂次 → 221 = 2097152
- 构造时显式传入：new ConcurrentHashMap(2097152)
- 负载因子保持默认 0.75 即可；调大（如 0.9）会加剧哈希冲突，链表变长，拖慢性能
遍历时接受弱一致性，不强求实时准确
ConcurrentHashMap 的迭代器不会抛 ConcurrentModificationException，但可能漏掉刚插入的项，或看到已删除项的旧值——这是设计使然，不是 bug。
- 适用于监控统计、日志采集、后台扫描等非强一致性场景
- 强行用外部同步或复制全量数据做“强一致遍历”，既没意义又严重拖慢系统
- 若业务真需要某时刻的精确快照，说明设计上应考虑事件驱动或状态快照机制，而非依赖 Map 遍历
