Java8中分组的复杂性

我想了解下面给定语句的时间复杂性

---

有什么想法吗？

这个问题没有一般的答案，因为时间复杂度取决于所有操作。由于必须完全处理流，因此基本时间复杂度为

O（n）

，必须乘以每个元素完成的所有操作的成本。这是假设迭代成本本身并不比

O（n）

差，这是大多数流源的情况

因此，假设没有影响时间复杂度的中间操作，

groupingBy

必须评估每个元素的函数，该函数应独立于其他元素，因此不会影响时间复杂度（无论它有多昂贵，因为

O（…）

时间复杂性只告诉我们，时间是如何随着大量流元素而扩展的）。然后，它将把元素插入到映射中，这可能取决于已包含元素的数量。如果没有自定义的

Map

供应商，则Map的类型是未指定的，因此，此处不能进行任何说明

在实践中，可以合理地假设结果是某种哈希映射，默认情况下具有净

O（1）

查找复杂性。因此，分组的净时间复杂度为

O（n）

。然后，我们有下游收集器

默认的下游收集器是

toList（）

，它生成一个未指定的

列表

类型，因此，我们同样不能说明向其添加元素的成本

当前的实现生成一个

ArrayList

，当超过容量时，它必须执行复制操作，但是由于容量每次都会增加一个因子，因此添加n个元素的净复杂性仍然是

O（n）

。可以合理地假设，未来对

toList（）

实现的更改不会使成本比我们现在的成本更高。因此，默认的

groupingBy

集合的时间复杂度很可能是

O（n）

如果将自定义

Map

采集器与自定义下游采集器一起使用，则复杂性取决于平均组数与每组元素数的比率。最坏的情况是地图的查找和下游收集器的元素处理（乘以元素数），因为我们可以有一个包含所有项目的组，或者每个项目都在自己的组中

但通常，您能够预测特定分组操作的偏差，因此您希望计算该特定操作的时间复杂度，而不是依赖于关于所有分组操作的语句。

是的，通过某个对象的getter进行分组似乎为0（n），

list.stream().collect(groupingBy(...));