今天介绍Map的merge方法，让我们来看看它的强大之处。
在JDK的API中，这样的一个方法它是很特别的，它很新颖，它是值得我们花时间去了解的，同时也推荐你可以运用到实际的项目代码中，对你们应该帮助很大。Map.merge（）。这可能是Map中最通用的操作。但它也相当模糊，几乎很少人会去使用它。
背景介绍
merge()可以解释如下：它将新的值赋值给到key中（如果不存在）或更新具有给定值的现有key（UPSERT）。让我们从最基本的例子开始：计算唯一的单词出现次数。在java8之前的时候，代码非常混乱，实际的实现其实已经失去了本质层面的设计意义。
var map = new HashMap<String, Integer>();
words.forEach(word -> {
var prev = map.get(word);
if (prev == null) {
map.put(word, 1);
} else {
map.put(word, prev + 1);
}
});
按照上述代码的逻辑，假设给定一个输入集合，输出的结果如下；
var words = List.of("Foo", "Bar", "Foo", "Buzz", "Foo", "Buzz", "Fizz", "Fizz");
//...
{Bar=1, Fizz=2, Foo=3, Buzz=2}
改进V1
现在让我们来重构它，主要去掉它的一些判断逻辑；
words.forEach(word -> {
map.putIfAbsent(word, 0);
map.put(word, map.get(word) + 1);
});
这样的改进，是可以满足我们的重构要求。putIfAbsent()的具体用法就不过多描述。putIfAbsent那一行代码是一定需要的，否则，后面的逻辑也就会报错。而在下面代码中，又出现了put、get这一点会很奇怪，让我们再继续的进行改进设计。
改进V2
words.forEach(word -> {
map.putIfAbsent(word, 0);
map.computeIfPresent(word, (w, prev) -> prev + 1);
});
computeIfPresent是仅当 word中的的key存在的时候才调用给定的转换。否则它什么都不处理。我们通过将key初始化为零来确保key存在，因此增量始终有效。这样的实现是不是已经足够完美？未必，还有其他的思路可以减少额外的初始化。
words.forEach(word ->
map.compute(word, (w, prev) -> prev != null ? prev + 1 : 1)
);
compute ()就像是computeIfPresent()，但无论给定key的存在与否如何都会调用它。如果key的值不存在，则prev参数为null。将简单移动if 到隐藏在lambda中的三元表达式也远远没有达到最佳的表现。在我向你展示最终版本之前，让我们看一下稍微简化的默认实现Map.merge()源码分析。
改进V3
merge()源码
default V merge(K key, V value, BiFunction<V, V, V> remappingFunction) {
V oldValue = get(key);
V newValue = (oldValue == null) ? value :
remappingFunction.apply(oldValue, value);
if (newValue == null) {
remove(key);
} else {
put(key, newValue);
}
return newValue;
}
代码片段胜过千言万语。 阅读源码总是能够发现新大陆，merge() 适用于两种情况。如果给定的key不存在，它就变成了put(key, value)。但是，如果key已经存在一些值，我们 remappingFunction 可以选择合并的方式。这个功能是完美契机上面的场景：
- 只需返回新值即可覆盖旧值： (old, new) -> new
- 只需返回旧值即可保留旧值：(old, new) -> old
- 以某种方式合并两者，例如：(old, new) -> old + new
- 甚至删除旧值：(old, new) -> null
如你所见，它 merge() 是非常通用的。那么，我们的问题该如何使用merge()呢？代码如下：
words.forEach(word ->
map.merge(word, 1, (prev, one) -> prev + one)
);
你可以按照如下思路理解：如果没有key，那么初始化的value等于1；否则，将1添加到现有值。代码中的 one 是一个常量，因为我们的场景中，默认一直是加1，具体变化可以随意切换。
场景
想象一下，merge()真的那么好用吗？它的场景可以有什么？
举一个例子。你有一个帐户操作类
class Operation {
private final String accNo;
private final BigDecimal amount;
}
以及针对不同帐户的一系列操作：
operations = List.of(
new Operation("123", new BigDecimal("10")),
new Operation("456", new BigDecimal("1200")),
new Operation("123", new BigDecimal("-4")),
new Operation("123", new BigDecimal("8")),
new Operation("456", new BigDecimal("800")),
new Operation("456", new BigDecimal("-1500")),
new Operation("123", new BigDecimal("2")),
new Operation("123", new BigDecimal("-6.5")),
new Operation("456", new BigDecimal("-600"))
);
我们希望为每个帐户计算余额（总运营金额）。假如不用merge()，就变得非常麻烦了：
Map balances = new HashMap<String, BigDecimal>();
operations.forEach(op -> {
var key = op.getAccNo();
balances.putIfAbsent(key, BigDecimal.ZERO);
balances.computeIfPresent(key, (accNo, prev) -> prev.add(op.getAmount()));
});
使用merge之后的代码
operations.forEach(op ->
balances.merge(op.getAccNo(), op.getAmount(),
(soFar, amount) -> soFar.add(amount))
);
再进行优化的逻辑。
operations.forEach(op ->
balances.merge(op.getAccNo(), op.getAmount(), BigDecimal::add)
);
当然结果是正确的，这样简洁的代码心动吗？对于每个操作，add在给定的amount给定accNo。
{ 123 = 9.5，456 = - 100 }
ConcurrentHashMap
当我们再延伸到ConcurrentHashMap来，当 Map.merge的出现，和ConcurrentHashMap的结合那是非常的完美的。这样的搭配场景是对于那些自动执行插入或者更新操作的单线程安全的逻辑。