问题描述
通过使用两个收集器的经验，这种模式变得显而易见。您会在Stackoverflow上找到一些问题和解答，无论使用哪种收集器都可以解决问题，但是其中一个似乎更适合特定任务。
这是归约和可变归约之间差异的变体。在第一种情况下，我们reduce在Stream上使用，在第二种情况下，我们使用collect。很自然，当我们想将可变约简应用于组时groupingBy，以秒Collector为参数的收集器是正确的工具。
并不是很明显，当我们要执行经典的归约时，toMap采用 合并
函数的收集器是正确的工具，因为该归并函数具有与归约函数相同的形状和目的，即使未如此调用也是如此。
在实践中，我们注意到执行还原操作的收集器返回Optional，通常与一起使用时不希望这样做groupingBy，这就是toMap在这种情况下工作更顺畅的原因。
使用这些API时，肯定会有更多的模式变得明显，但是将它们收集在一个答案中并不是Stackoverflow的范围。
解决方法
我大约提高了一些代码，以前也问了一个问题在这里。@霍尔格给了我正确的回答，他说：
每当发现自己通过groupingBy使用reducer收集器时，都应检查toMap是否更合适
好像是花样！他建议我做的只是完美的。
这是众所周知的模式吗？为什么toMap比（在某些情况下）结合groupingBy和更好reducing？