О «маркировке» объекта во время сборки мусора или Рихтер был не прав

Сегодня речь пойдет о бесполезной, с практической точки зрения, информации о внутренностях CLR и сборщика мусора.

Многие из нас изучали внутренности .NET и CLR по книге Джеффри Рихтера “CLR via C#”. Книга просто замечательной, глубокая, детальная и очень точная. Но, как это обычно бывает, даже Рихтер иногда ошибается (пусть и в деталях).

Вот цитата:

When the CLR starts a GC, the CLR first suspends all threads in the process. This prevents threads from accessing objects and changing their state while the CLR examines them. Then, the CLR performs what is called the marking phase of the GC. First, it walks through all the objects in the heap setting a bit (contained in the sync block index field) to 0. This indicates that all objects should be deleted. Then, the CLR looks at all active roots to see which objects they refer to. This is what makes the CLR’s GC a reference tracking GC. If a root contains null, the CLR ignores the root and moves on to examine the next root.

Any root referring to an object on the heap causes the CLR to mark that object. Marking an object means that the CLR sets the bit in the object’s sync block index to 1. When an object is marked, the CLR examines the roots inside that object and marks the objects they refer to. If the CLR is about to mark an already-marked object, then it does not examine the object’s fields again. This prevents an infinite loop from occurring in the case where you have a circular reference.

И что же здесь не так?

Элегантная реализация «слабых событий»

Камрад @v2_matveev указал на прекрасную реализацию слабых событий в коде Roslyn-а.

Проблема стара как мир: подписка на события долгоживущего объекта со стороны короткоживущего продлевает время жизни последнего. Сложно? Может быть. Но столкнуться с проблемой довольно легко: если у вас есть синглтон с событиями, поздравляю, в вашем приложении есть эта проблема и связанные с ней утечки памяти. Поскольку событие содержит корневую ссылку на хендлер, то любой подписчик будет жить до тех пор, пока он не отпишется от события или пока поставщик событий не умрет (что в случае синглтона произойдет лишь при выгрузке домена или окончания работы приложения).

Решается эта проблема разными способами. Самый правильный способ – не использовать события в синглтонах. Второй способ – отписываться от событий вовремя. Третий способ – хипстерский, воспользоваться той или иной реализацией Weak Event Pattern-а, например, с помощью WeakEventManager или чего-то подобного. Но раз уж зашла речь за слыбые события, то их можно реализовать по разному и далее показана самая изящная реализация.

Вначале демонстрируем проблему: добавляем синглтон с событиями и короткоживущий объект, который на них подписывается:

О сборке мусора и достижимости объектов

DISCLAIMER: это относительно продвинутая статья о сборке мусора, поэтому автор предполагает минимальное знакомство читателя с принципом работы сборщика мусора CLR.

Вопрос: может ли объект стать достижимым для сборки мусора до окончания вызова конструктора?

Поскольку объект не может контролировать процесс своего уничтожения, то этот вопрос можно перефразировать так: может ли финализатор вызваться до окончания вызова конструктора?

Но вместо того, чтобы сразу отвечать на эти вопросы, давайте рассмотрим основные особенности сборки мусора и ответим на более простые вопросы.

Слабые ссылки в .NET

Никогда не задумывались о том, что значит булевый флаг trackResuraction в конструкторе WeakReference и что же такое short weak reference и long weak reference? Есть шансы, что вы не задумывались об этом просто потому, что никогда этих зверей не использовали в своем коде. Я тоже не особо задумывался об этой разнице, но вот, давеча, решил разобраться с этими вещами более подробно.

ПРИМЕЧАНИЕ
Разница между short и long weak references существует лишь при работе с финализируемыми объектами. Выходит, что это весьма специфическая тема, но ее рассмотрение позволит чуть глубже разобраться с внутренним устройством и поведением сборщика мусора.

Итак, давайте вспомним, что происходит при создании объекта А, содержащего финализатор:

Немного о сборке мусора и поколениях

Все знают о том, что для повышения эффективности сборки мусора большинство современных систем используют поколения. Но вы когда-нибудь задумывались о том, как вообще эти поколения работают, и за счет чего мы получаем выигрыш в производительности? Но давайте не будем забегать вперед и разберем все по порядку.

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

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

Источники о сборке мусора в .NET

Я тут недавно проводил курс по сборке мусора и в результате накопилось немалое количество источников, которые были бы полезны любому, кто хочет освоить эту тему более подробно. Ну, а чтобы дело не пропадало даром, я думаю будет здорово этими источниками поделиться.

Книги

1. Under the Hood of .NET Memory Management by Chris Farrell and Nick Harrison
   Книга не большая (225 страниц), посвященная сборке мусора на платформе .NET и описанию типовых проблем работы с памятью и советов по их устранению. Очень неплохая книга, с достаточной глубиной изложения, но без особых дебрей и заумностей; основные моменты изложены хорошо, но я бы посоветовал относиться с осторожностью к некоторым советам по оптимизации и не забывать, что к ним нужно приступать только после профилирования.
   Электронная версия книги свободна доступна в Сети.
2. Advanced .NET Debugging by Mario Heward
   Книга не по сборке мусора непосредственно, но в ней покрыты очень многие низкоуровневые детали, которые можно «пощупать» с помощью отладки. Очень толково написано, хотя иногда бывает перебор с количеством низкоуровневых деталей.
3. Pro .NET Performance by Sasha Goldstein at al
   Интересная книга по производительности в целом, но и с разделом по сборке мусора. Книга кажется очень интересной, а точное мнение о ней, я надеюсь у меня появится через месяц-другой после ее прочтения.
4. CLR via C# by Jeffrey Richter
   Классика. Хотя в этом плане здесь не менее полезной будет практически любая хорошая книга по языку C# и платформе .NET. C# 4 Unleashed, например, тоже подойдет для знакомства с этой темой.