2012-08-23 3 views
0

Я много читал об этой теме, и все же у меня нет четкого пути к продолжению. Может ли кто-нибудь указать на какой-то ресурс (или объяснить), который показывает подробный шаг, как найти причину, по которой некоторые объекты dctor не вызываются.Решение проблем с утечкой памяти

в основном моя логика для тестирования утечки это (WPF приложение):

  1. создать некоторый вид/ViewModel
  2. закрыть окно
  3. вызова GC.Collect()

После несколько секунд обычно называется dctor в классе ViewModel, но в моем приложении никогда не вызывается. Я хотел бы знать, какой объект ссылается на него в то время, поскольку, на мой взгляд, это способ найти причину утечки памяти.

В этих классах нет неуправляемых ресурсов и не реализовано IDisposable, что означает отсутствие вызова SupressFinalize для предотвращения выполнения дескриптора.

Редактировать: ViewModel извлекается через свойство Static в ViewModelLocator и добавляется список. Это требуется TabControl, для которого требуется набор моделей просмотра для привязки. View и ViewModel подключаются через DataTemplate.

+0

Этот вопрос трудно ответить, не зная, как вы используете свой viewModel – mydogisbox

+0

Apologiez. Я думал, что метод обнаружения утечки памяти для большинства сценариев одинаковый. Я добавляю информацию о том, как использовать VM – Goran

+0

На стороне примечания, если ваши классы не используют неуправляемые ресурсы, вам действительно не нужно реализовывать финализатор для них; состояние объекта во время финализации таково, что вы не должны предполагать, что вы можете получить доступ к любым управляемым ссылкам, которые ранее были действительными для класса во время его жизни. Финализаторы предназначены только для неуправляемой очистки (а затем действительно только в качестве резервной копии для надлежащего детерминированного удаления). –

ответ

0

Во-первых, найдите непереданные обработчики событий и статические ссылки, указывающие на вашу ViewModel, даже косвенно. Поскольку вы находитесь в приложении WPF, также убедитесь, что вы не используете DependencyPropertyDescriptor.AddValueChanged, который, как известно, вызывает утечки с помощью статических ссылок.

Если вы не можете найти что-либо вручную, используйте удивительный (это мое мнение, я никоим образом не связан с ними) SciTech .NET Memory Profiler. Вы можете видеть для каждого объекта все ссылки, которые он содержит, и какие другие объекты содержат ссылку на него, в красивом графике . Он также предупреждает вас об общих проблемах памяти. не

EDIT:

ViewModel извлекается через статическое свойство на ViewModelLocator

поиск больше не, у вас есть утечка. Статические ссылки не позволяют объектам собирать мусор. Удалите статическую ссылку или оберните ее в WeakReference.

+0

Привет, Жюльен, я скорректировал ViewModelLocator для использования одноэлементного шаблона, поэтому никаких статических свойств. Когда мы говорим о некорректных обработчиках событий, я использовал много анонимных методов в своем приложении. Например, для каждого RelayCommand (MVVM light framework) я использую анонимный метод, поэтому нет никакой подписки. Может ли это создать утечку памяти? Я спрашиваю об этом, потому что с.Профилировщик NET-памяти Я получаю много сообщений о типах косвенных корней делегата, и я вижу, что в некоторых входах сообщаются ICommands. – Goran

Смежные вопросы