为什么 Stack<T> 和 Queue<T> 用数组实现？答案

【问题标题】：Why are Stack<T> and Queue<T> implemented with an array?为什么 Stack<T> 和 Queue<T> 用数组实现？
【发布时间】：2011-03-01 08:01:39
【问题描述】：

我正在阅读 Albahari 兄弟的 C# 4.0 in a Nutshell，我发现了这个：

堆栈是通过根据需要调整大小的数组在内部实现的，与队列和列表一样。（第 288 页，第 4 段）

我不禁想知道为什么。 LinkedList 提供 O(1) 头尾插入和删除（这应该适用于堆栈或队列）。可调整大小的数组具有 O(1) 分期插入（如果我没记错的话），但 O(n) 最坏情况（我不确定删除）。而且它可能比链表使用更多的空间（对于大型堆栈/队列）。

还有比这更多的吗？双向链表实现的缺点是什么？

【问题讨论】：

还有一点是底层数组是循环使用的，所以数组元素在头部和尾部移动时被回收（如果没有超出边界）。
三个字：内存管理开销。
@SebastianNegraszus 谢谢。你是怎么找到的？我搜索了很多，没有找到任何东西。
@KooKoo 是本页“相关”下的热门链接之一。我不能说我是否会通过搜索找到它。

标签： c# .net stack queue linked-list

【解决方案1】：

但 O(n) 最坏情况

摊销的最坏情况仍然是 O(1)。插入时间的长短均化——这就是摊销分析的重点（删除也是如此）。

数组也比链表使用更少空间（毕竟链表必须为每个元素存储一个额外的指针）。

此外，开销比使用链表要少得多。总而言之，对于几乎所有用例来说，基于数组的实现（非常）效率更高，即使偶尔访问会花费更长的时间（实际上，队列可以通过以下方式更有效地实现）页面本身在链接列表中管理的优势 - 请参阅 C++'std::deque 实现。

【讨论】：

@Femaref：不——它真的叫deque，而不是dequeue。
另外，使用数组会给你带来局部性的好处。
哦，对不起。拼写“queue”是一个很常见的错误，所以我以为你上当了，无意冒犯。

【解决方案2】：

这里粗略估计了 100 个System.Int32s 堆栈所使用的内存资源：

数组实现需要以下内容：

type designator                          4 bytes
object lock                              4
pointer to the array                     4 (or 8)
array type designator                    4
array lock                               4
int array                              400
stack head index                         4
                                       ---
Total                                  424 bytes  (in 2 managed heap objects)

链表实现需要以下内容：

type designator                          4 bytes
object lock                              4
pointer to the last node                 4 (or 8)
node type designator         4 * 100 = 400
node lock                    4 * 100 = 400
int value                    4 * 100 = 400
pointer to next node  4 (or 8) * 100 = 400 (or 800)
                                     -----
Total                                1,612 bytes  (in 101 managed heap objects)

数组实现的主要缺点是在需要扩展数组时复制数组。忽略所有其他因素，这将是一个 O(n) 操作，其中 n 是堆栈中的项目数。这似乎是一件非常糟糕的事情，除了两个因素：它几乎从未发生过，因为每次递增时扩展都会加倍，并且数组复制操作经过高度优化并且速度惊人。因此，在实践中，扩展很容易被其他堆栈操作淹没。

队列也是如此。

【讨论】：

您的假设仅对值类型是正确的。如果 T 是引用类型，则两种实现都需要几乎相同的资源。因为数组条目将是每个项目对堆元素的引用。
@MichaelBarabash - 这取决于您所说的“几乎相同”是什么意思。如果您将我给出的示例从 Int32 转换为引用类型，那么一切都是一样的，只是您将引用类型值的存储添加到两者中，这将是完全相同的。如果您使用的是 64 位，那么您还将存储值的大小加倍以适应更大的引用，但无论哪种方式，两种方法的总大小都会增加完全相同的数量。因此，链表使用的附加存储仍然是附加的。（续...）
但是，您正确的意思是链表开销将占总数的较小比例。
嗨，杰弗里，完全同意。

【解决方案3】：

这是因为 .NET 是为在现代处理器上运行而设计的。这比内存总线快得多。处理器以大约 2 GHz 的速度运行。您机器中的 RAM 的时钟频率通常为几百兆赫。从 RAM 中读取一个字节需要超过一百个时钟周期。

这使得 CPU 缓存在现代处理器上非常重要，大量的芯片空间被烧毁以使缓存尽可能大。今天的典型情况是 64 KB 用于 L1 高速缓存，这是最快的内存，并且物理位置非常靠近处理器内核，L2 高速缓存为 256 KB，速度较慢且离内核较远，L3 高速缓存约为 8 MB，速度较慢且最远离开，由芯片上的所有内核共享。

为了使缓存有效，顺序访问内存非常重要。如果需要 L3 或 RAM 存储器访问，读取第一个字节可能非常昂贵，接下来的 63 个字节非常便宜。 “缓存线”的大小，内存总线的数据传输单位。

这使得 array 成为迄今为止最有效的数据结构，它的元素按顺序存储在内存中。链表是迄今为止最糟糕的数据结构，它的元素自然地分散在内存中，可能会导致每个元素的高速缓存未命中。

因此，所有 .NET 集合，除了 LinkedList 都在内部实现为数组。请注意， Stack 已经自然地实现为数组，因为您只能从数组末尾推送和弹出元素。 O(1) 操作。调整数组大小的摊销成本为 O(logN)。

【讨论】：