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

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

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

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

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

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

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

Ответ 1

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

Я не уверен, что ваш случай касается слабых ссылок...

Ответ 2

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

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

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

Ответ 3

Я рекомендую вам проверить "другие" ссылки на объекты с низкой ссылкой. Поскольку, если есть еще одна ссылка еще живая, объекты не будут GCed.

Ответ 4

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