Почему сборщик "мусора" не может выяснить, когда объекты, ссылающиеся друг на друга, являются действительно осиротевшими
Поэтому ожидайте, он:
md5(filename) + timestamp
или:
md5(filename + timestamp)
, Если бы первый, Вы - большая часть пути к GUID, и я не волновался бы об этом. Если последний, то см. сообщение Karg о том, как Вы столкнетесь с коллизиями в конечном счете.
5 ответов
Ваше предположение неверно. Если GC «видит» (см. Ниже) циклическую ссылку на 2 или более объектов (во время фазы «Mark»), но на них не ссылаются никакие другие объекты или постоянные дескрипторы GC (сильные ссылки), эти объекты будут собраны (во время фаза «развертки»).
Более подробный обзор сборщика мусора CLR можно найти в этой статье MSDN и в этом сообщении в блоге .
Примечание: на самом деле, GC не " Они даже не «видят» эти типы объектов во время фазы mark , поскольку они недоступны и, следовательно, собираются во время сканирования .
Большинство сборщиков мусора больше не работают со счетчиком ссылок. Обычно они (и это имеет место как в Java, так и в .NET) работают с возможностью доступа из корневого набора объектов. Корневой набор объектов - это глобальные объекты и экземпляры со ссылками на стек. Все, что прямо или косвенно доступно из этого набора, живо. Остальная часть памяти недоступна и поэтому может быть собрана.
Я хотел бы добавить, что проблемы, связанные с подпиской на события, обычно связаны с тем фактом, что у подписчика и издателя очень разные жизненные циклы.
Присоединитесь, например, к событию App.Idle в Windows Forms, и ваш объект будет оставаться активным в течение оставшегося времени жизни приложения. Почему? Это статическое приложение будет содержать ссылку (хотя и косвенно через делегата) на вашего зарегистрированного наблюдателя. Даже если вы, возможно, удалили своего наблюдателя, он по-прежнему прикреплен к App.Idle. Вы можете построить многие из этих примеров.
Это главный недостаток традиционной сборки мусора с подсчетом ссылок . Свойство сборщика мусора, описывающее такое поведение, - неполный сборщик. Другие сборщики в значительной степени попадают в категорию, называемую сборщиками мусора трассировки , которые включают традиционные метки-очистку, полупространство / уплотнение и гибриды поколений, и не страдают этими недостатками (но сталкиваются с некоторыми другими).
Все известные мне реализации JVM и CLI используют полные сборщики , что означает, что они не страдают от конкретной проблемы, о которой вы здесь спрашиваете. Насколько мне известно, из этих Jikes RVM - единственный, поставляющий сборщик подсчета ссылок (один из многих).
Еще одна интересная вещь, на которую стоит обратить внимание, - это решения проблемы полноты в сборке мусора с подсчетом ссылок, и полученные сборщики демонстрируют некоторые интересные свойства производительности, которые трудно избежать при отслеживании сборщиков. К сожалению, наиболее эффективные алгоритмы сборки мусора с подсчетом ссылок и большинство модификаций полноты полагаются на помощь компилятора, поэтому их перенос в C ++ shared_ptr затруднен / не происходит. Вместо этого у нас есть weak_ptr и задокументированные правила (извините за неоптимальную ссылку - видимо, документация ускользает от меня) о простом избежании проблем. Это не первый раз (еще одна посредственная ссылка), который мы видели такой подход,
Остальные ответы здесь, безусловно, верны; .NET выполняет сборку мусора в зависимости от доступности объекта.
Что я хотел добавить: я могу порекомендовать прочитать Общие сведения о сборке мусора в .NET (простая статья Эндрю Хантера), если вам нужна более подробная информация.