ConcurrentHashMap线程安全但非万能：JDK8+用CAS+synchronized实现分段锁，get无锁、put仅锁bin头节点；复合操作须用computeIfAbsent等原子方法；size()和isEmpty()返回近似值；key/value需自身线程安全且key应不可变。
ConcurrentHashMap 是线程安全的，但不是万能锁
它通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）实现高并发读写，**不阻塞全部操作**。这意味着 get() 几乎无锁，而 put() 只锁定对应 bin 的头节点——但如果你手动用 synchronized 包裹整个 map 操作，反而会抵消它的并发优势。
别在循环里直接调用 remove() 或 computeIfAbsent() 做复合逻辑
像“检查是否存在 → 不存在则创建”这种逻辑，看似简单，但分开写 containsKey() + putIfAbsent() 仍可能引发竞态：两次调用之间其他线程已插入。正确做法是用原子方法：
map.computeIfAbsent(key, k -> {
// 这里创建新对象的逻辑只会在 key 确实不存在时执行一次
return new ExpensiveObject(k);
});
-
computeIfAbsent()和merge()是原子的，适合构建缓存场景 - 避免在 lambda 中抛出受检异常（需包装为 RuntimeException）
- 如果初始化逻辑可能失败且需重试，不要依赖 computeIfAbsent 自动重入——它不保证重试，失败即返回 null 或抛异常
size() 和 isEmpty() 不是强一致性快照
这两个方法返回的是近似值。JDK 8+ 中 size() 实际调用 sumCount()，遍历每个 segment 的 baseCount 和 counterCells 数组，但过程中其他线程仍在修改，结果可能滞后一个更新周期。实际业务中：
- 不要用
size() == 0判断是否可安全关闭资源——改用map.isEmpty()虽也不绝对可靠，但语义更清晰 - 需要精确计数？改用
LongAdder单独维护计数器，或用mappingCount()（返回 long，比size()更准确，但仍非严格实时） - 遍历时别依赖 size() 控制 for 循环次数，改用
entrySet().iterator()或增强 for
key 和 value 仍需保证自身线程安全
ConcurrentHashMap 只保证 map 结构操作的线程安全，不约束 key/value 对象内部状态。例如：
立即学习“Java免费学习笔记（深入）”；
ConcurrentHashMap<String, StringBuilder> map = new ConcurrentHashMap<>();
map.computeIfAbsent("log", k -> new StringBuilder()).append("msg"); // ❌ 危险！StringBuilder 非线程安全
- value 是可变对象（如
ArrayList、SimpleDateFormat）时，外部仍需同步或改用不可变/线程安全替代品（如CopyOnWriteArrayList、DateTimeFormatter） - key 最好是不可变类（如
String、Integer），否则若 key 在插入后被修改导致hashCode()变化，后续get()将找不到该 entry - 自定义 key 类必须正确重写
hashCode()和equals()，且二者逻辑不能依赖可变字段
