map.replace(k,v) 仅在键存在时替换值，不插入新键值对；replace(k,v,v) 需键存在且旧值引用相等才替换，常用于乐观更新，但注意 null、不可变 map 及类型约束问题。
Map.replace() 本身就有“仅存在时才更新”的语义
Map.replace(K key, V value) 不会插入新键值对，只在 key 已存在于 map 中时，才用 value 替换原有 value。这是它的默认行为，不是需要额外判断的“技巧”——它天然就是安全的。
常见误解是把它和 put() 混淆，后者不管键存不存在都会写入；而 replace() 是“有才换，无则跳过”。
- 如果 key 不存在，方法直接返回
null（或void，取决于重载版本），且 map 不变 - 如果 key 存在，返回旧 value，并把 value 更新为传入的新值
- 注意：它不检查 value 是否相等，只要 key 存在就强制替换
区分 replace(K,V) 和 replace(K,V,V) 两个重载
Java 的 Map 接口定义了两个关键重载：
-
replace(K key, V value)：如上所述，仅存在时替换，不校验旧值 -
replace(K key, V oldValue, V newValue)：只有当 key 存在 且 当前 value 等于oldValue（引用相等，非equals()）时，才替换为newValue
第二个重载常用于并发场景下的乐观更新，比如避免覆盖别人刚写入的新值。但要注意：它用的是 == 判断旧值，不是 equals()，所以对字符串字面量或 interned 对象安全，对 new String() 或自定义对象要格外小心。
实际使用中容易踩的坑
最常出问题的地方不在逻辑，而在类型和 null 处理：
- 传入的
key为null时，是否允许取决于具体实现（HashMap允许，ConcurrentHashMap不允许，会抛NullPointerException） - 如果 map 是由 Guava 的
ImmutableMap构建的，调用replace()会直接抛UnsupportedOperationException—— 它连replace()方法都只是继承自接口，实际不可变 - 用
TreeMap时，key 必须可比较，否则运行时报ClassCastException，这个错误往往发生在 replace 前没暴露，replace 时才触发 - 不要依赖
replace()的返回值做业务判断而不检查是否为null，尤其在不确定 key 是否存在的场景下
替代方案：当 replace() 不适用时该用什么
如果你发现 replace() 无法满足需求，通常是因为要“存在才更新，且需基于旧值计算新值”，这时推荐：
- 用
computeIfPresent(K key, BiFunction super K, ? super V, ? extends V> remappingFunction)：只在 key 存在时执行函数，函数参数是 key 和当前 value，返回新 value（可为null，表示删除） - 避免手写
if (map.containsKey(k)) map.put(k, ...)：这有竞态风险（两次哈希查找 + 非原子操作），尤其在多线程下 - 如果必须严格基于旧值做条件更新（比如“若当前值 > 100 则加 10”），
computeIfPresent更清晰安全；replace(K,V,V)只适合“精确匹配旧值”的简单场景
真正复杂的状态更新逻辑，别硬塞进单个 map 方法里，封装成独立函数再配合 computeIfPresent 或 merge() 更可控。
