Исключения и утечки памяти

Question

Это теоретический вопрос больше всего на свете. В случае C # и .NET, если сценарий .aspx или .ascx умирает из-за необработанного исключения, вы обычно ожидаете освобождения его памяти или это не совсем так? Другими словами, может ли необработанное исключение само по себе вызвать утечку памяти?

Answer 1

Что такое «утечка памяти»?В средах с ручным управлением мы говорим, что выделенные ссылки - это утечка.По этому определению в среде ГХ нет утечек.

Однако есть несколько сценариев, которые имеют такой же эффект:

Устаревшие ссылки

// create temporary item
Item item = new Item();

// add it to the global map, so Processor::Fetch finds it by ID
itemMap.Add(item.id, item);
Process(item.id);

// remove from cache
itemMap.Remove(item.id);

Если выдает Process (), элементостается ссылкой в ​​itemMap.Если вы регулярно не выбрасываете всю карту (или не приняли мудрое решение использовать слабые указатели для карты), карта элементов будет накапливать и хранить ссылки на временные блоки, блокируя память.

Неуправляемые ресурсы

Представьте, что у вас есть небольшой управляемый объект, который выделяет большие неуправляемые ресурсы и не реализует IDisposable, или IDisposable не используется.

Эти объекты могут жить достаточно долго, чтобы их подтолкнуть кGen 2. Если в управляемой куче нет никакого давления другое , коллекция Gen 2 может никогда не запуститься.В конечном итоге вы можете столкнуть крошечные объекты в Gen 2, пока неуправляемые ресурсы не исчерпают вашу память.

Этот сценарий может показаться глупым, но именно так работает COM Interop (и у меня есть идентификатор случая, чтобы доказать это).

Answer 2

Нет, обычно, если все, что вы используете, - это .NET, это единственный способ утечки памяти, если вам нужно избавиться от неуправляемых ресурсов.

Для некоторых объектов c # для этой цели предусмотрена функция "release" или "dispose".

Answer 3

Это не предполагается , и я никогда не видел, чтобы это произошло; но сборщику мусора может потребоваться много времени, чтобы очистить его, иногда до тех пор, пока вы «не используете» значительную часть доступной памяти.