数组声明：全局与本地

Question

为什么在全局可能的情况下，为什么不能在主函数内部或本地任何函数内部声明10000000个整数（或者说足够大）的数组？

Answer 1

tl; dr：局部变量的空间有限。 这就是CPU和操作系统的工作方式。

---

这是一个实现细节，许多语言和实现（例如，典型台式机OS上的C，C ++）都共享该实现细节。

代码在其上运行的大多数平台都留出了一些称为“ 堆栈”的内存，用于返回地址和本地存储。 这只是CPU（Intel，AMD等）如何执行机器代码的详细信息。

从堆栈的分配非常快，但是只有在函数调用返回之前，内存才有效。 这使其非常适合C / C ++局部变量。

但是，堆栈空间有限，因此即使在“其他位置”仍有足够的内存，大的分配也会因堆栈溢出而失败。

程序启动时分配全局变量的内存。 例如，可执行文件将指示“我需要那么多的空间填充零，并且我需要那么多的数据空间，以及那么多的代码空间。”

“第三个”内存位置是堆 ：用于通过malloc / new等分配的malloc 。在堆上的分配比在堆栈上的分配要贵（并且有更多的问题要解决），它们会一直存在直到您释放为止他们，既好又是负担。

---

一些旁注，由于与问题不直接相关，因此特意省略：

堆栈只是一系列（连续的）内存，您只能在其中分配和释放内存。 这使其受到限制，方便且快速。

在现代台式机系统上，32位进程通常不会再耗尽内存，而是会耗尽地址空间：仍然有物理内存可用，但是32位字中的所有可用地址都会用完。

每个执行线程都有自己的堆栈，而全局变量和堆在进程的所有线程之间共享。

---

为何编译器不将大量分配移到其他地方？

首先，“一直都是这种方式”。 许多现有代码可能会巧妙地依赖于旧的行为，并且“改进”编译器可能会破坏此代码。

其次，由于各种原因，唯一普遍适用的“其他位置”是堆。 堆栈和堆分配之间的性能差异非常明显：

• 堆分配更昂贵
• 堆是共享的，因此必须同步从多个线程对堆的访问，这可能会非常昂贵。
• 堆栈的顶部几乎总是在CPU的高速缓存中（因为地址范围的访问非常频繁）。 堆更有可能不会

在大多数情况下，这些细节无关紧要，但是对于某些操作而言，这种差异是很明显的。 如果编译器决定在堆上分配一些分配，我们将失去可预测性。

Answer 2

（编辑：全局变量通常不会进入堆）

这可能是由于可用堆栈内存和总内存之间的差异。 局部变量放在堆栈中，而全局变量放在静态分配的内存部分中。 以下是一个比较通用的问题，可以很好地回答程序内存分配问题：

堆栈或堆中C ++中的全局内存管理？