问更糟糕的是时间复杂度put/get HashMap

EN

是的，在最坏的情况下，您的哈希映射将退化为一个链接列表，您将遭受O(N)查找以及插入和删除的惩罚，这两个选项都需要一个查找操作(感谢我在前面的答复中指出了错误的注释)。

有一些减轻最坏情况行为的方法，例如使用自平衡树而不是存储桶溢出的链接列表，这样可以将最坏情况的行为减少到O(logn)而不是O(n)。

在Java8的HashMap实现中(当键类型实现Comparable时)：

使用平衡树处理频繁的HashMap冲突:在高哈希冲突的情况下，这将提高从O(n)到O(log )的最坏情况性能。

来自这里。

在打开散列时，您将有一个链接列表来存储具有相同哈希代码的对象。因此:例如，您有一个大小为4.1的散列表)，假设您想用hashcode = 0存储一个对象。然后将对象映射到索引(0 mod 4=) 0。2)然后再次使用hashcode = 8放置另一个对象。该对象将映射到索引(8 mod 4=) 0，因为我们记得索引0已经填充了第一个对象，所以我们必须将第二个对象放在第一个对象的旁边。

[0]=>linkedList{object1, object2}
[1]=>null
[2]=>null
[3]=>null

3)搜索的步骤是什么?第一，您必须散列关键对象并假定它的哈希码为8，因此您将被重定向到索引(8 mod 4=) 0，然后由于同一索引中存储了多个对象，所以我们必须逐个搜索列表中所有存储的对象，直到找到匹配的对象或直到列表的末尾为止。由于示例中有两个存储在相同哈希表索引0中的对象，而搜索的对象正好位于链接列表的末尾，因此您需要遍历所有存储的对象。这就是为什么最坏的情况是O(n)。最糟糕的情况是，当所有存储的对象都在哈希表中的同一索引中时发生。因此，它们将被存储在一个链接列表中，在其中我们(可能)需要遍历所有的链接列表，以找到我们搜索的对象。

希望这能帮上忙。