Как сборщик мусора решает, когда убивать объекты, хранящиеся в WeakReferences?

Question

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

Стандартное объяснение WeakReferences состоит в том, что GC игнорирует их при выполнении своих операций развертки. Тем не менее, мой объект переживает вызов GC.Collect (GC.MaxGeneration, GCCollectionMode.Forced).

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

Обновление и заключение

Основной причиной было то, что в стеке была ссылка, которая блокировала объект. Неясно, почему ни SOS, ни SOSEX не показывали эту ссылку. Ошибка пользователя всегда возможна.

В ходе диагностики первопричины я провел несколько экспериментов, которые продемонстрировали, что слабые ссылки на объекты 2-го поколения могут оставаться на удивление долгое время. Однако объект WRd 2-го поколения не сможет пережить GC.Collect (GC.MaxGeneration, GCCollectionMode.Forced).

Answer 1

Объекты со слабой ссылкой do удаляются сборщиком мусора. Я имел удовольствие отлаживать системы событий, где события не запускались ... Оказалось, что подписчик имел слабую ссылку, и поэтому после некоторой случайной задержки GC в конечном итоге собирал его. В этот момент пользовательский интерфейс перестал обновляться. :)

Answer 2

Попробуйте позвонить GC.WaitForPendingFinalizers() сразу после GC.Collect().

Еще один возможный вариант: никогда не используйте WeakReference для каких-либо целей. В дикой природе я только когда-либо видел, чтобы они использовались в качестве механизма для уменьшения объема памяти приложения (то есть формы кэширования). Как могучий MSDN говорит:

Избегайте использования слабых ссылок в качестве автоматическое решение для памяти проблемы управления. Вместо этого развиваться эффективная политика кэширования для обработка объектов вашего приложения.

Answer 3

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

Answer 4

Согласно википедии «Объект, на который ссылаются только слабые ссылки, считается недостижимым (или« слабо достижимым ») и может собираться в любое время. Слабые ссылки используются, чтобы избежать сохранения памяти, на которую ссылаются ненужные объекты»

Я не уверен, что в вашем случае речь идет о слабых ссылках ...