Предотвращение утечек памяти с приложенными поведениями

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

Microsoft даже признает, что это утечка памяти:

Почему реализация шаблон WeakEvent?

Прислушивание к событиям может привести к утечкам памяти. Типичная техника для слушания события состоит в том, чтобы использовать определенный для языка синтаксис, который присоединяет обработчик к событию на источнике. Например, в C#, тот синтаксис: источник. SomeEvent + = новый SomeEventHandler (MyEventHandler).

Эта техника создает сильную ссылку от источника события до слушателя события. Обычно, присоединение обработчика событий для слушателя заставляет слушателя иметь объектное время жизни, что под влиянием объектного времени жизни для источника (если обработчик событий явно не удален). Но при определенных обстоятельствах Вы могли бы хотеть, чтобы объектное время жизни слушателя управлялось только другими факторами, такой как, принадлежит ли оно в настоящее время визуальному дереву приложения, а не ко времени жизни источника. Каждый раз, когда время жизни исходного объекта расширяется вне объектного времени жизни слушателя, нормальный шаблон события приводит к утечке памяти: слушатель поддерживается дольше, чем предназначенный.

Мы используем WPF для клиентского приложения с крупным ToolWindows, который может быть перетащен отброшенный, весь изящный материал и все совместимые с в XBAP.. Но у нас была та же проблема с некоторыми ToolWindows, которые не были собраны "мусор".. Это было то, вследствие того, что это все еще зависело от слушателей события.. Теперь это не могло бы быть проблемой, когда Вы закрываете свое окно и закрываете Ваше приложение. Но если Вы создаете очень крупный ToolWindows с большим количеством команд, и все эти команды переоценены много раз, и люди должны целый день использовать Ваше приложение.. Я могу сказать Вам.. это действительно забивает Вашу память и время отклика Вашего приложения..

Кроме того, я нахожу намного легче объяснить моему менеджеру, что у нас есть утечка памяти, чем объяснение ему, что некоторые объекты не собраны "мусор" из-за некоторых событий, которому нужна очистка ;)

@Nick Да, вещь с приложенными поведениями состоит в том, что по определению они не находятся в том же объекте как элементы, события которых Вы обрабатываете.

Я думаю, что ответ заключается в рамках использования WeakReference так или иначе, но я не видел простых примеров кода, чтобы объяснить это мне.:)

Вы имеете хотя из реализации "Слабого Шаблона События" вместо регулярных событий?

1. Слабый шаблон события в WPF
2. Слабые шаблоны события (MSDN)

Удостоверьтесь, что элементы ссылки события с в объекте, на который они ссылаются, как текстовые поля в управлении формой. Или если это не может быть предотвращено. Создайте статическое событие на глобальном классе помощника и затем контролируйте глобальный класс помощника для событий. Если эти два шага не могут быть сделаны попытка с помощью WeakReference, они обычно идеально подходят для этих ситуаций, но они идут наверху.

Я просто считал Ваше сообщение в блоге, и я думаю, что Вы получили немного вводящего в заблуждение совета, Matt. Если существует фактическая утечка памяти здесь, то это - ошибка в Платформе.NET и не чем-то, что можно обязательно зафиксировать в коде.

Что я думаю, что Вы (и плакат на Вашем блоге) на самом деле говорите о, вот не на самом деле утечки, а скорее продолжающегося потребления памяти. Это не то же самое. Чтобы быть ясной, пропущенная память является памятью, которая зарезервирована программой, затем отказалась (т.е., указатель оставляют, свисая), и который впоследствии не может быть освобожден. Так как памятью управляют в.NET, это теоретически невозможно. Возможно, однако, для программы зарезервировать постоянно увеличивающийся объем памяти, не позволяя ссылки на него выйти из объема (и стать имеющим право на сборку "мусора"); однако та память не пропущена. GC возвратит его системе, после того как Ваша программа выходит.

Так. Для ответа на вопрос я не думаю, что у Вас на самом деле есть проблема здесь. У Вас, конечно, нет утечки памяти, и из Вашего кода, я не думаю, что необходимо волноваться, насколько потребление памяти идет также. Пока Вы удостоверяетесь, что неоднократно не присваиваете тот обработчик событий без никогда de-присвоения это (т.е., что Вы или только когда-либо набор это однажды, или что Вы удаляете его точно однажды в течение каждого раза, когда Вы присваиваете его), то, которое Вы, кажется, делаете, Ваш код, должно быть прекрасным.

Кажется, что это - совет, который плакат на Вашем блоге пытался дать Вам, но он использовал ту сигнализирующую работу "утечка", которая является страшным словом, но из которой многие программисты забыли реальное значение в управляемом мире; это не применяется здесь.

@Arcturus:

... забейте свою память и подайте Вашу заявку, действительно замедляются, когда они не собраны "мусор".

Это ослепляюще очевидно, и я не не соглашаюсь. Однако:

... Вы пропускаете память, чтобы возразить, что Вы больше не используете..., потому что существует ссылка на них.

"память выделяется программе, и та программа впоследствии теряет способность получить доступ к ней из-за дефектов логики программы" (Википедия, "Утечка памяти")

Если существует активная ссылка на объект, к которому может получить доступ Ваша программа, то по определению это не пропускает память. Утечка означает, что объект больше не доступен (для Вас или для ОС/платформы) и не будет освобожден в течение времени жизни текущей сессии операционной системы. Дело обстоит не так здесь.

(Извините, что был семантическим нацистом..., возможно, я - немного старая школа, но утечка имеет очень определенное значение. Люди склонны использовать "утечку памяти" в эти дни для значения чего-либо, что использует 2 КБ памяти больше, чем они хотят...),

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

Верный верный,

Вы правы, конечно.. Но существует совершенно новое поколение программистов, рождающихся в этот мир, который никогда не будет касаться неуправляемого кода, и я действительно полагаю, что определения языка переосмыслят себя много раз. Утечки памяти в WPF таким образом отличаются, чем говорят C/Cpp.

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

Что касается проблемы Matt, это могла бы быть проблема производительности, которой Вы, возможно, должны были бы заняться. Если Вы просто используете несколько экранов, и Вы делаете те, которые экран управляет одиночными элементами, Вы не могли бы видеть эту проблему вообще ;).

Хорошо это (менеджер укусил) я могу, конечно, понять и сочувствовать.

Но независимо от того, что Microsoft называет его, я не думаю, что "новое" определение является соответствующим. Это сложно, потому что мы не живем в 100% управляемый мир (даже при том, что Microsoft нравится притворяться, что мы делаем, сама Microsoft не живет в таком мире). Когда Вы говорите, что утечка памяти, могли подразумевать, что программа использует слишком много памяти (это - определение пользователя), или что управляемая ссылка не будет освобождена до выхода (как здесь), или что неуправляемая ссылка правильно не очищается (который был бы утечкой реальной памяти), или что неуправляемый код, названный из управляемого кода, пропускает память (другая реальная утечка).

В этом случае очевидно, что означает "утечка памяти", даже при том, что мы неточны. Но это становится ужасно утомительным говорящий с некоторыми людьми, которые называют каждое сверхпотребление или failure-collect утечка памяти; и печально, когда эти люди являются программистами, которые, предположительно, знают лучше. Для технических терминов довольно важно иметь однозначные значения, я думаю. Отладка настолько легче, когда они делают.

Так или иначе. Не означайте превращать это в легкую дискуссию о языке. Просто высказывание...