我们都知道,创建促进重用的小方法是一种很好的做法,这不可避免地会导致大量方法被放置在堆栈中。但是,是否有可能达到这样的场景,即有如此多的嵌套方法调用而发生StackOverflow异常?
可接受的解决方案是简单地增加堆栈大小吗?
该文档指出,在“非常深或无界递归”期间会发生这样的异常,因此这似乎是可能的,或者 .NET 框架是否为我们动态处理堆栈大小?
我的问题可以这样概括:
是否有可能拥有这样一个设计良好的程序(就小型可重用方法而言)来增加堆栈大小并因此使用更多资源?
我们都知道,创建促进重用的小方法是一种很好的做法,这不可避免地会导致大量方法被放置在堆栈中。但是,是否有可能达到这样的场景,即有如此多的嵌套方法调用而发生StackOverflow异常?
可接受的解决方案是简单地增加堆栈大小吗?
该文档指出,在“非常深或无界递归”期间会发生这样的异常,因此这似乎是可能的,或者 .NET 框架是否为我们动态处理堆栈大小?
我的问题可以这样概括:
是否有可能拥有这样一个设计良好的程序(就小型可重用方法而言)来增加堆栈大小并因此使用更多资源?
.NET 堆栈大小是固定的,默认为 1 MB。
是否有可能拥有这样一个设计良好的程序(就小型可重用方法而言)来增加堆栈大小并因此使用更多资源?
它不会将您的逻辑分解为方法。
遇到不是直接错误的堆栈溢出的唯一方法是递归。当这种情况发生(威胁)时,不要增加堆栈,而是重写代码以使用不同的方式存储数据(如 a Stack<T>
)。
并不真地。我刚刚做了一个非常快速的测试,在 15,000 次嵌套调用之后发生了 StackOverflowException。
由于您拥有的方法数量众多,您将无法编写非递归嵌套 15,000 次的代码。
显然,确切的数字取决于您在堆栈上分配的许多函数局部变量。但无论实际数字是多少,它都远远不足以满足您的建议。
在托管世界中,堆栈对性能具有特殊作用。如果您设法在堆栈上分配某些东西(使用原语或结构),则不必将其放在堆上。在堆上分配会增加 GC 压力,这平均会减慢程序的速度。
所以我可以通过在堆栈上分配很多东西来想象一个更快的程序。即使使用stackalloc(这是 C#/CLR 的一个鲜为人知的特性)。
有有效的案例可以做到这一点。它们很少见。仅仅说“没有有效的用途”是完全错误的。