大家都知道 Stack 就是分配给每个线程的一块内存，大小为1MB ，它存储对ReferenceType的引用（ObjRef）、用户结构、原始数据和方法的局部变量。
现在的问题是：当 Stack 完全填满时， CLR会做什么，因此，基本上没有什么可删除的。也就是说，Stack 已满？
CLR 可以将其边界从 1MB 扩展到 2MB 吗？（或者这是不可能的，所以我们只会得到一个异常，通知我们堆栈溢出）。
另一个问题：在不安全代码的上下文中，unamanged 内存也分配了 1MB，或者可以分配自定义大小？
首先，值得注意的是，代码执行时的堆栈并不是某种抽象的安全机制。.NET 使用 JIT 编译，因此特定于平台的代码实际上是使用该平台的堆栈机制执行的。在x86的情况下，一个栈段+一对SS/ESP寄存器和push/pop操作。没有为不安全创建单独的堆栈。
当堆栈已满时会发生什么，达到限制时是否可以增加？不，一般来说，你不能。
事实上，至少在 x86/64 中，栈是一种从末尾开始填充的数据结构。那些。堆栈上的每一次推送都会将其指针移动到更靠近开头的位置。这来自内存稀缺的古代（.net 之前）时代，标准内存共享如下所示：
物理内存在堆和栈之间划分，程序员总是有选择——为堆上的东西分配更多的内存，或者把更多的对象放在栈上。此外，这种布局有效地消除了单独控制堆大小和单独控制堆栈的需要。因为 如果堆和栈在其中相遇，则根本没有内存。
从那以后发生了很多变化（尽管上面的布局在某些微控制器上仍然相关）。在 x86 中，堆栈现在通常分配一个单独的段。但是，根据传统，它是从最后填充的。那些。每个入栈操作都会减少 SP 的值，减去栈中内容的大小。
当 ESP 达到 0 时，处理器会抛出错误。x86 中没有在堆栈上“添加内存”的机制 - 仅仅是因为不可能在段的开头“添加”内存 - 并且处理器不敢在末尾分配内存并将所有数据移动到堆栈 - 这对它来说太复杂了。操作系统可以做到这一点，但至少 x86 上的 Windows 不能。
在出口处，当堆栈指针达到 0 时，您将
StackOverflowException进入 .NET 代码。这是达到“铁”堆栈极限的指示器，而不是一些棘手的 CLR 堆栈。值得注意的是
StackOverflowException无限递归也可能导致 x86，即使你没有声明局部变量。关键是 x86 方法调用机制 (call) 将调用方法的返回地址保存在堆栈上。返回运算符 (ret) 从堆栈中弹出地址。因此，太深的调用链会阻塞堆栈。实际上，这就是调用视图窗口被称为调用堆栈的原因——返回链上的信息仅存储在堆栈中。在 x86 上 - 在与函数参数和局部变量相同的物理堆栈中。