computeIfAbsent 适用于key不存在时按需初始化并缓存结果，如为新key自动创建ArrayList；不适用于覆盖已有key的值，此时应使用put或compute；其lambda不可抛受检异常，否则需包装为RuntimeException，且若抛异常会直接向外抛出。
computeIfAbsent 什么时候该用，什么时候不该用
它只在 key 不存在时才执行计算逻辑并存入值，适合「按需初始化 + 缓存结果」的场景。比如缓存一个复杂对象、懒加载集合、避免重复构造。
但如果你只是想「覆盖旧值」或「不管存不存在都更新」，那就别用——computeIfAbsent 在 key 已存在时直接返回旧值，根本不会调用你传的 lambda，容易误以为逻辑被执行了。
- 适合：构建
Map<string list>></string>时，为新 key 自动 new ArrayList() - 不适合：想给已有 key 更新值（该用
put或compute） - 特别注意：lambda 里不能抛受检异常，否则得包装成 RuntimeException
lambda 里抛异常会卡住吗
会，而且不是“卡住”，是直接抛出——computeIfAbsent 的函数式参数类型是 Function super K, ? extends V>，它不声明抛异常，所以你在 lambda 里 throw IOException 这类受检异常，编译就过不去。
- 解决办法：用 try-catch 包一层，把受检异常转成
RuntimeException，比如new RuntimeException(e) - 别写
throw new Exception()——编译失败 - 如果 lambda 里调用了可能阻塞的方法（如远程请求），那整个
computeIfAbsent就会同步阻塞，影响并发性能
和 getOrDefault + put 组合比，有啥实际区别
表面看都能实现“没值就设默认”，但底层行为完全不同：前者是原子操作，后者是两步非原子操作，在多线程下可能重复初始化。
立即学习“Java免费学习笔记（深入）”；
比如两个线程同时查 key 不存在，都走 getOrDefault 返回 null，然后都执行 put，后一个会覆盖前一个——如果初始化代价高（比如建连接、解析大文件），就白干了一次。
-
computeIfAbsent底层用 synchronized 或 CAS 保证 key 不存在时只执行一次 lambda -
getOrDefault+put是竞态条件高发区，尤其在ConcurrentHashMap里也不安全（因为判断和插入不是一体的） - 性能上，
computeIfAbsent多一点方法调用开销，但省去了重复计算的代价，通常更划算
返回值是不是一定等于你放进去的值
不一定。如果 map 实现类重写了 computeIfAbsent（比如某些自定义 Map），或者你用的是非标准并发 map，行为可能不同；但对 JDK 自带的 HashMap 和 ConcurrentHashMap，返回值就是 lambda 计算出的那个对象引用。
- 重点陷阱：lambda 返回 null ——
computeIfAbsent允许，但有些 map 实现（如 Guava 的ImmutableMap）根本不支持 null 值，会直接 NPE - 另一个坑：lambda 返回的对象被外部修改（比如返回了内部缓存的
ArrayList），后续读取可能拿到脏数据 - 别依赖返回值做 == 判断，要用
equals——即使同一次调用，返回值和 map 里 get 出来的也未必是同一个引用（极少情况，但某些代理 map 会 wrap）
