我有一个大的工作array的struct在.NET类型，这远远比分配堆栈（每个线程）的标准1MB的。我现在只关心主线程。
我读了一篇旧文章（可能已过时），其中提到了明确调整堆栈大小：http : //content.atalasoft.com/h/i/58213648-increasing-the-size-of-your-stack-net-memory-management -第3部分
我注意到，stackoverflow exceptions在32位模式下，但不是在64位模式下（我感兴趣的主要模式），我的程序经常崩溃。
在32位模式下，您需要显式增加堆栈的大小。
.NET框架在64位模式下为您隐式调整堆栈的大小（即使此行为与64位模式不一致）。
C＃和VB.NET编译器无法指定主线程的初始堆栈大小。C ++ / CLI编译器可以。否则，在生成后事件中使用Editbin.exe是一个简单的解决方法。
未公开此选项，因为对于托管代码，默认堆栈大小非常大。与非托管语言（如C和C ++）不同，没有简单的方法来使用声明消耗大量堆栈。数组和字符串是引用类型，因此是在GC堆而不是堆栈上分配的。
唯一有效的方法是使用unsafestackalloc关键字，这是您永远不会偶然使用的关键字。还是通过递归，要么是偶然的（到目前为止是最常见的情况），要么是使用比O（logN）更差的递归算法。这样的问题严重倾向于bug，Editbin.exe只是一个创可贴，因为当数据集足够大时，您仍然会感到烦恼。
仅需要注意的其他细节是，如果专门针对x64 ，则初始堆栈大小将为4MB而不是1MB 。通常也有一个错误，您总是喜欢AnyCPU。
因此，否则的盲目建议是开始寻找该递归代码。它不应离生成SOE的语句很远，至少在堆栈跟踪中可见。注意O（N）尾部递归，您不能指望它得到优化，绝对不是32位代码。考虑替换它或对其进行分区，或者对数据集大小添加检查，并抢先引发异常。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句