Comments 17
Если эта тема показалась вам интересной и вы хотите больше подобного контента - рекомендую подписаться на мой свежеиспеченный телеграм канал https://t.me/dk_growth
Можете привести пример, как используя эти знания можно оптимизировать код приложения и сделать его более производительным?
Кто нибудь может объяснить, почему именно этот алгоритм выбран, а не на основе кол-ва ссылок?
Подсчет ссылок не решает проблему циклических ссылок. Собственно, в том же python именно поэтому есть и reference counting и generational gc
Понял. Т.е. это единственная причина, по которой выбран алгоритм, страдающий от остановки мира? Просто хочу уточнить. А то для себя я за годы уже привык избегать структур с циклическими ссылками. Вот мне и кажется, что это меньшее зло, чем использовать алгоритм с таким проблемами производительности. Я оговорюсь, что очень большой проблемой я это не считаю, но судя по кол-ву статей на эту тему, как в русскоязычной, так и в англоязычной сфере, кто-то всё же считает это проблемой. Так вот, если это всё же проблема, то почему же выбран алгоритм, подверженный этой проблеме? Неужели всего-лишь из-за того, что он может обрабатывать циклические ссылки?
Сборщики мусора могут не только удалять не используемые объекты, но и, например, еще выполнять memory compaction или дефрагментацию. Насчет stw, то почти все современные gc прибегают к нему. В статьях, обычно, критикуют именно выбор достаточно старого и простого трехцветного алгоритма.
По поводу избегания циклических ссылок, то тут не все так однозначно. Пока кодовая база маленькая и количество разработчиков коммитящих в нее немного, то все ок. Но по мере роста команды и кода за этим будет следить все сложнее, да и в сторонних либах может быть все что угодно)
по поводу избегания циклических ссылок: но ведь если они нужны для реализации графа который по бизнес-логики заложен - как избавиться от такого? делать менее оптимальные варианты через матрицу смежности?
отличная статья, спасибо! ждём ещё
будет ли статья по тому, как работает планировщик горутин?
Если эта тема показалась вам интересной и вы хотите больше подобного контента - рекомендую подписаться на мой свежеиспеченный телеграм канал https://t.me/dk_growth
Рассмотрим алгоритм логически, по шагам:
Покрасить все корневые объекты (стек и глобальные переменные) в серый.
Выбрать серый объект из набора серых объектов и пометить его как чёрный.
(Из какого набора серых объектов? Мы же только что ВСЕ объекты покрасили в серый. Т.е. выбрать рандомно объект?)Все объекты, на которые указывает чёрный объект, пометить серым. Это гарантирует, что сам объект и объекты, на которые он ссылается, не будут выброшены в мусор.
(Так, мы покрасили ОДИН объект из ВСЕХ черным. Дальше мы все объекты, на которые указывает этот черный объект, помечаем серым. То есть на этом шаге мы не делаем НИЧЕГО)Если в графе остались серые объекты, вернуться к шагу 2.
(Естественно они ОСТАЛИСЬ, только если объект не был единственным в этом "наборе". При этом если возможна ситуация, когда серый объект указывает на черный, получаем бесконечный цикл)
Итого, логически доказано, что алгоритм А) красит все объекты в серый цвет. Б) затем рандомно в цикле выбирает по одному объекту и красит их в черный цвет, пока все объекты не становятся черными. Тогда почему сразу все в черный цвет не покрасить уже на первом шаге? Статья как будто chatGPT написана
Go's Garbage Collection: как работает и почему это важно знать