Если вы пишете рекурсивные функции, которые хранят локальные стековые ссылки на больших данных, которые не нужны при субрекурсивных вызовах, то это тип утечки пространства, но очень редко бывает так, чтобы это было проблемой на практике .
В целом, если у вас есть что-то вроде
Main() {
var s = ReadInAGiganticString(); // say 10 Megs long
Server(s.Substring(0,5)); // but I only care about first 5 chars
}
Server(s) {
while(true) { ... } // but 10M is on stack forever
}
тогда это своего рода утечка стекового пространства, но на практике это маловероятно. Исправить несложно:
Main() {
var s = ReadInAGiganticString();
var t = s.Substring(0,5);
s = null; // the fix
Server(t);
}
Server(s) {
while(true) { ... }
}
В общем, если у вас когда-либо есть гигантская переменная в стеке непосредственно перед вызовом, который будет длиться «долго», и эта переменная больше не будет использоваться, вы можете обнулить ее, чтобы убедиться, что она может быть перед GC'd входя в «длинный» вызов.
(Возможно, что оптимизатор может сделать это для вас на основе анализа достижимости.)
Обратите внимание, что приведенный выше ответ предназначен для ссылок на объекты, выделенные в куче, которые находятся в стеке. Если, с другой стороны, у вас есть выделенная в стеке память (например, гигантская структура или stackalloc thingie), то это исправить не так просто, но на практике это еще реже (кто когда-либо создает гигантские структуры?).