Есть ли хороший способ выполнить разыменование объектов WPF / C # для сборки мусора?

Question

Фон приложения

Наша платформа является WPF-приложением, запускаемым нажатием одной кнопки. У нас есть «оболочка», которая содержит структуру меню навигации и содержит наши собственные классы «страницы». Когда вы переходите на новую страницу, мы меняем содержимое оболочки (по сути).

Проблема

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

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

У нас нет возможности рефакторинга каждой страницы (в этом выпуске). Есть ли способ с C # удалить все ссылки из объекта? (Поэтому разрешает сборщику мусора выбросить этот объект вместе со всеми его внутренними ссылками)

Мы пытаемся вернуть эту память, но довольно сложно найти объекты, которые все еще ссылаются на наши страницы (ссылки на объекты), когда мы имеем дело с WPF.

Мы рассмотрели визуальные и логические деревья и использовали приложения для профилирования, чтобы помочь нам очистить вещи вручную (для проверки идеи), и это оказалось чрезвычайно сложным.

Я откинулся на спинку кресла и подумал, почему мы делаем всю эту работу, чтобы найти ссылки на объекты, не можем ли мы просто «разыменовать» эту «страницу», когда она закрыта?

Что приводит меня сюда:)
Любая помощь с благодарностью!

---

ОБНОВЛЕНИЕ 1

В комментариях спрашивалось следующее:

Q: Есть ли приложение. на самом деле есть проблемы с памятью? Как они выставлены / обнаружены? Или эта память болтается до GC2? - Митч Пшеничный

A: Проблемы с памятью. Если мы покидаем страницу (свойство, содержащее страницу, устанавливается на новый объект), старый объект никогда не собирается сборщиком мусора. Так что память просто продолжает расти. Если наша компания начала заново, с этим приложением. Первое, на что мы должны обратить внимание, это реализовать шаблоны WeakEvent и использовать больше маршрутизируемых команд в WPF.

ОБНОВЛЕНИЕ 2

Я смог найти собственное решение .

Answer 1

Вы использовали CLRProfiler? Я нахожу это довольно хорошим для поиска объектов, а также для нахождения ссылок на них.

Эта страница "Как сделать" ...

http://msdn.microsoft.com/en-us/library/ms979205.aspx

... ссылки на сайт загрузки.

Тем не менее, я думаю, что ответ на ваш вопрос "нет". Нельзя сказать, что «объект foo больше не требуется - соберите его, независимо от того, является ли он рутом или нет». Сбор корневого объекта может привнести в приложение всевозможные недостатки.

Answer 2

Я реализовал Слабые события , чтобы решить эту проблему.

К сожалению, Microsoft рекомендует использовать их WeakEventManager в качестве базового класса и создать тип менеджера для КАЖДОГО события в вашем приложении !!! Я попытался написать менеджер, который наследует от этой базы и сделать его более «универсальным» (не в термине C # для универсального). Этот «обычный» менеджер событий был невозможен в базовом классе Microsoft. Мне пришлось написать менеджер событий с нуля.

Спасибо за любую помощь, опубликованную на этот вопрос.

Answer 3

Если страница дыры выходит за рамки, включая все базовые данные, GC будет собирать ее. В конце концов. Однако, если на эту страницу ссылается что-либо, находящееся в области видимости, страница и все ее данные останутся в памяти, и GC не сможет их собрать.

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

Вы можете предложить GC пройти его алгоритм, чтобы узнать, можно ли что-нибудь собрать, вызвав GC.Collect (). Однако это будет очень мало, кроме ненужных циклов ЦП, если данные действительно не выходят за рамки.

Вопрос к Phobis, сколько памяти использует ваше приложение?

EDIT:

Ссылка на CLR Profiler 2.0, который должен работать для приложений .net3.5. http://www.microsoft.com/downloads/details.aspx?familyid=a362781c-3870-43be-8926-862b40aa0cd0&displaylang=en