Внедрение WeakReference в .NET

Question

Я понимаю и ценю полезность класса System.WeakReference в .NET Framework, но мне интересно узнать подробности реализации.

Как работает WeakReference в .NET? MSDN подробно обсуждает использование WeakReference, но имеет небольшие детали, которые я видел о том, как это работает под капотом.

Как CLR отслеживает ссылку и знает, чтобы исключить внутренний дескриптор при сборке цели, не предотвращая GC? Требуется ли специальная обработка в самой CLR?

Моя основная забота заключается в том, будут ли последствия использования WeakReferences влиять на производительность (особенно если они используются для многих из них), которые отличаются от характеристик использования стандартных ссылок на объекты.

Answer 1

Класс WeakReference передает ссылку на объект в GC и получает ручку назад. Всякий раз, когда вы получаете ссылку или проверяете, поддерживает ли ссылка, дескриптор используется для запроса GC для справки.

Это означает, что GC хранит список всех слабых ссылок, которые он должен обновлять при сборе объектов. Это также означает, что при использовании слабой ссылки есть некоторые накладные расходы.

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

Answer 2

Вы упомянули MSDN; вы уже видели эту статью?

http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

Также проверьте главу 19 в "Applied Microsoft .NET Framework Программирование" того же автора (Jeffrey Richter). Эта глава посвящена сбору мусора и содержит раздел о внутренних компонентах WeakReference.

В общем, если вы получаете доступ к большому количеству Targets внутри WeakReferences, то это происходит просто потому, что WeakRef выполняет некоторую работу (главным образом для обеспечения безопасности потоков) перед возвратом цели. Это, очевидно, не так дешево, как использование ссылки на объект напрямую. С другой стороны, вы получаете некоторую производительность при хранении ссылок на большие объекты, поскольку сборщик мусора имеет больше возможностей при возникновении соображений памяти.

Я никогда не пытался количественно оценить этот компромисс или знать какие-либо ссылки здесь. Очевидно, что это зависит от приложения.