スタックサイズやオーバーフローの可能性があるメソッドが多すぎる可能性はありますか？

Question

再利用を促進する小さなメソッドを作成することは良い方法であり、必然的に多くのメソッドがスタックに配置されることは避けられません。しかし、非常に多くのネストされたメソッド呼び出しがあり、StackOverflow例外が発生するシナリオに到達することは可能ですか？

単純にスタックサイズを増やすことはできますか？

documentation states「非常に深いまたは無制限の再帰」の間にそのような例外が発生する可能性があるので、確かに可能であるか、.NETフレームワークが動的にスタックサイズを処理しますか？

私の質問はそうのようにまとめることができます。

は、それが（小さな再利用可能な方法の 換算）などうまく設計されたプログラムを持つことが可能です スタックサイズ、ひいてはを高めるためにnecassaryになっていることより多くのリソースを使用しますか？

Answer 1

私はちょうど非常に迅速なテストを行い、StackOverflowExceptionは15,000のネストされた呼び出しの後に発生します。

メソッドの数が非常に多いため、非再帰的に15,000回ネストするコードを書く方法はありません。

明らかに正確な数は、スタックに割り当てた多くの関数ローカル変数に依存します。しかし、実際の数が何であれ、それはあなたが示唆していることを行うのに十分近いところです。

Answer 2

.NETスタックサイズは固定されており、デフォルトでは1 MBです。

は、それがスタックサイズを増やし、したがって、より多くのリソースを使用することが必要になっている（小さな再利用可能な方法の点で）、そのようなうまく設計されたプログラムを持つことは可能ですか？

あなたのロジックをメソッドに分解することはありません。

直接のバグではないスタックオーバーフローが発生する唯一の方法は、再帰です。そしてそれが起こると（脅かされる）、スタックを増やさずに、コードを書き換えて別の方法でデータを保存します（Stack<T>など）。

Answer 3

管理対象の世界では、スタックはパフォーマンスのために特別な役割を持ちます。スタック上に（プリミティブや構造体を使って）何かを割り当てることができれば、それをヒープに置く必要はありません。ヒープに割り当てるとGCの負荷が加わり、平均的にプログラムが遅くなります。

私はスタック上にたくさんのものを割り当てることでより速いプログラムをイメージすることができました。 stackalloc（これはあまり知られていないC＃/ CLRの機能です）を使用しています。

これを行う有効なケースがあります。彼らはまれです。単に「有効な用途がない」と言っても間違っています。