Сборка мусора из статических элементов

Question

Будут ли сборщики мусора когда-либо статические члены?

Answer 1

Объекты, на которые ссылаются статические переменные, будут собирать мусор только тогда, когда соответствующий AppDomain собирает мусор. В клиентских приложениях часто есть только один AppDomain, который живет в течение всего процесса. (Исключением является случай, когда приложение использует архитектуру плагинов - разные плагины могут загружаться в разные AppDomain с, а AppDomain может выгружаться позже.)

В ASP.NET периодически происходит «AppDomain переработка» (по разным причинам) - когда это происходит, и статические переменные в этом AppDomain больше не будут действовать как корни GC и, следовательно, не будут препятствовать объектам мусор.

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

Answer 2

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

Answer 3

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

Чем дольше ответ ... Потенциально, тем лучше; сборщик мусора основывает свое решение собирать объект на достижимости объекта, а не на ссылках (сильных или слабых) на объект. Теоретически, если сборщик мусора может определить, что ни одному коду не потребуется снова определенный объект с определенной точки (т. Е. Объект недоступен из любого пути кода), GC будет разрешено собирать этот объект, даже если если бы на него все еще ссылались статические поля-члены класса. Это вполне допустимо, поскольку вы никогда не заметите, поскольку ни один код не будет пытаться получить доступ к полю члена статического класса, содержащему ссылку на объект. Вы можете спросить, почему меня волнует, что я больше никогда не получу доступ к объекту через какие-либо сильные ссылки на него? Причина, по которой вы будете беспокоиться, это побочные эффекты. Например, вы можете предположить, назначив в поле статического члена класса ссылку на объект SafeHandle, представляющий неуправляемый ресурс, что объект SafeHandle никогда не будет закрыт и, таким образом, будет поддерживать неуправляемый «объект», который он представляет, живым. Это верно только для текущих реализаций GC. Будущая реализация GC могла бы собирать объекты, на которые строго ссылаются статические поля-члены класса, если эти объекты больше не были доступны любому из оставшегося программного кода.

Answer 4

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