为什么 LinkedList 的 javadoc 不能保证 pop 和 push 的恒定时间性能？答案

【问题标题】：Why the javadoc of LinkedList does not guarantee constant time performance in pop and push?为什么 LinkedList 的 javadoc 不能保证 pop 和 push 的恒定时间性能？
【发布时间】：2015-07-29 10:11:10
【问题描述】：

在 Java 集合框架中，很多实现都提到了它们在 Javadoc 中的性能。例如，HashSet 说：

假设散列函数将元素正确地分散在桶中，此类为基本操作（添加、删除、包含和大小）提供恒定的时间性能。迭代这个集合需要的时间与 HashSet 实例的大小（元素的数量）加上支持 HashMap 实例的“容量”（桶的数量）之和成正比。

ArrayList 说：

size、isEmpty、get、set、iterator 和 listIterator 操作在恒定时间内运行。

但 LinkedList 并没有说明它的性能。

我相信 LinkedList 的 pop 和 push 方法在恒定时间内运行，就像计算机科学中的链表一样。但我担心当我实现一个具有 LinkedList 参数的方法时可以假设。

LinkedList有什么理由不说它的性能吗？

【问题讨论】：

这是对类似问题的一个很好的回答：stackoverflow.com/questions/322715/…
LinkedList 似乎没有提及其任何操作的性能。我不知道为什么——这不仅仅是pop 和push。

标签： java collections linked-list javadoc

【解决方案1】：

HashMap.get(Object) 的 javadoc 也不能保证 O(1) 性能，但众所周知。

Javadoc 是关于契约，而不是实现。 API 合同通常关注行为，而不是性能 SLA。

_{影响契约的具体实现选择可能会记录在 javadoc 中，但这仍然属于“契约”的主题。}

【讨论】：

HashMap 保证“此实现为基本操作（get 和 put）提供恒定时间的性能，假设哈希函数将元素正确地分散在桶中。”所以我可以假设这些方法在恒定时间内运行。
我不认为HashMap.get(Object) 是真正的O(1)。如果以某些方式使用，它实际上可以是 O(1)。但是您提到的是合同，恕我直言，它需要比“实际上通常是 O(1)”更严格的数学断言。这是HashMap 无法实现的。首先，用户可能提供了错误的散列函数。其次，即使有一个好的哈希函数，当元素的数量大大超过哈希桶的数量时，时间显然与元素的数量成正比（如果桶是线性实现的），这意味着它真的是O(n)。