Почему NET сборщик мусора никогда не звонил?

Question

Я работаю над приложением, которое имеет проблемы с потреблением памяти. Если пользователь нажимает достаточно долго в приложении, он заканчивается исключением OutOfMemoryException.

Профилирование приложения с помощью «ANTI Memory Profiler» довольно долгое время, и, по моему мнению, нет «классической» утечки памяти (например, обработчики событий, которые препятствуют сбору мусора).

Но все объекты, которые остаются в памяти, имеют одну общую черту - они используют, прямо или косвенно, стандартный элемент управления .NET (например, TextBox, Numberbox), который реализует Finalizer. В «Графе хранения экземпляров памяти ANTS Memory» я вижу, что единственным экземпляром, который содержит ссылку на элементы управления, является .NET Finalizer Queue.

Ссылка сохранение графа (у меня не хватает репутации размещать изображения прямо :-)) ->http://i50.tinypic.com/2d6r6nn.png

Поэтому я исследовал в направлении взаимоблокировки в Finalizer тему (см http://dotnetdebug.net/2005/06/22/blocked-finalizer-thread/) но не смог найти показания для тупика. Кроме того, то, что против теории тупика, заключается в том, что после моментального снимка памяти с помощью Profiler Profiler, который запускает GC.Collect(), представления собираются с мусором, соответственно, их Finalizer выполняются, и все в порядке.

Итак, это похоже на нормальный жизненный цикл .net-объекта с Finalizer, правильно? Но в моем приложении я могу щелкнуть, пока OutOfMemoryException и сборщик мусора никогда не запустится!

Последняя попытка решить проблему состояла в использовании GC.AddMemoryPressure(), потому что в представлениях много растровых изображений, которые выделяют довольно много неуправляемого кода. Но и это не могло спровоцировать сборщика мусора для сбора свободной памяти.

Итак, я думаю, что в приложении есть что-то внутренне неправильное, что предотвращает освобождение GC от памяти, но я понятия не имею, что.

Неужели кто-то подвергся подобным переживаниям и имеет какую-либо подсказку?

С наилучшими пожеланиями

Andi

Answer 1

OutOfMemoryException иногда лежит. Иногда это означает, что «я не могу получить неуправляемый дескриптор» - это не вполне всегда фактически связано с памятью. Проблема в том, что часто бывает трудно сказать , почему что-то не получается, и «из памяти», вероятно, разумное предположение.

Это звуки, как и многие вещи, не были установлены быстро. Утилизация их вызвала бы их собственный код, чтобы с нетерпением и упреждающим выпуском их неповрежденных ручек.

GC, наоборот, в основном вызвано давлением памяти. В наши дни на ПК может остаться много памяти, но из-за неуправляемых ручек.

Answer 2

В MODEL-VIEW-VIEWMODEL (MVVM) можно было бы очистить объекты как элементы управления, если вы работаете со специальными ссылками третьей стороны.Может быть, вам просто нужно включить object.Dispose и object = null

When to dispose ViewModel in MVVM Light

Answer 3

Может быть много вещей

Это лишь одна странность, которая вызвала из памяти для меня

В множестве проверки для = значение, и если так, верните.

Ищите ненужные вызовы NotifyPropertyChanged.
У меня был случай, когда я загружал ObservableCollection через общедоступное свойство, и он был в очереди на несколько NotifyPropertyChanged и вызвал нехватку памяти.
Затем я загрузил частную переменную и только что вызвал NotifyPropertyChanged один раз, когда это было сделано, и исправлено нехватка памяти.