Хорошая практика для реализации обработки событий через WeakReference, если это событие является единственной вещью, содержащей ссылку, и что нам нужен объект для сбора мусора?WeakReference и обработка событий
В качестве аргумента к этому:
Люди говорят, что если вы подписались на то, что это ваша ответственность, чтобы отменить подписку, и вы должны это сделать.
В то время как то, что вы предлагаете, решает один набор проблем (управление ссылкой на события и предотвращение утечки памяти), он, вероятно, откроет новый набор проблем.
Одна из проблем, которые я вижу во время обработки событий, если исходный объект является сборкой мусора (поскольку он содержался только при слабой ссылке), любой код, который обращается к исходному объекту, приведет к исключению нулевой ссылки. Вы можете утверждать, что обработчик события должен либо не обращаться к исходному объекту, либо иметь сильную ссылку, но можно утверждать, что это может быть хуже, чем проблема, которую вы пытаетесь решить в первую очередь.
Слабый шаблон делегата - это то, что должно быть в CLR. Обычные события показывают «уведомлять меня, пока вы живы», а часто нам нужно «уведомить меня, пока я жив». Простое делегирование на WeakReference ошибочно, потому что делегат тоже объект, и даже когда получатель все еще жив и имеет входящие ссылки, делегат сам ссылается только на упомянутое WeakReference и будет немедленно собрано. См. this old post для примера реализации.
Слабые ссылки в своем собственном праве, не решают проблему, поскольку делегат держит ссылку. В составной библиотеке приложений, которая поставляется с Prism (www.microsoft.com/compositewpf), есть класс WeakDelegate, который вы можете извлечь из источника. The WeakDelegate в основном отражает и создает делегата только на мгновение, а затем освобождает его, тем самым не имея никаких указателей. В CAL он используется классом EventAggregator, но вы можете разрывать его для собственного использования, так как оно находится под MS-PL.
Хорошо, когда вы можете привыкнуть отказаться от подписки на события, но иногда нет очевидного метода «очистки», где это можно сделать. Недавно мы разместили blog article по этому вопросу; он включает методы, облегчающие подписку на событие с помощью WeakReference.
Вопрос: Каковы шансы, что это событие будет уволено к тому времени, когда объект будет собран мусором? Зачем использовать WeakReference в первую очередь? – 2008-10-09 04:27:15
@Jon Limjap без слабой референции, это не тот случайный ноль, потому что событие отслеживает объект и, следовательно, его не собирают? – fostandy 2011-04-21 04:55:19