Go использует триколорный конкурентный сборщик мусора, где объекты переходят из белого (неотмеченного) в серый (в очереди) и в черный (полностью просканированный). Основное правило во время маркировки заключается в том, что черные объекты никогда не должны содержать указатели на белые объекты, так как это позволило бы сборщику ошибочно освободить достижимую память. Чтобы обеспечить это, не останавливая систему, Go использует защитную преграду записи — вставляемый компилятором хук, который срабатывает при каждой записи указателя в кучу. Когда горутина-мутатор выполняет запись указателя, барьер проверяет, является ли целевой объект белым; если да, то он немедленно затеняет целевой объект в серый цвет перед завершением записи, атомарно сохраняя инвариант.
Мы наблюдали серьезную задержку в реальном времени в аналитическом конвейере, обрабатывающем миллионы событий в секунду. Система использовала сложную графовую структуру, где узлы часто обновляли ссылки на дочерние узлы на основе потоковых данных, что вызывало массовую смену указателей во время циклов сборки мусора Go.
Первое рассматриваемое решение: Мы попытались смягчить это, увеличив GOGC до 200%, чтобы отложить сборки. Плюсы: уменьшение частоты циклов сборки мусора, снижая общее количество выполнений барьера с течением времени. Минусы: это значительно увеличивало пик кучи, что создаёт риск аварийных остановок OOM на наших ограниченных по памяти контейнерах, и просто откладывало всплески задержки, а не решало их.
Второе рассматриваемое решение: Мы поэкспериментировали с пулом объектов, используя sync.Pool, чтобы повторно использовать структуры узлов и снизить количество аллокаций. Плюсы: уменьшение давления на аллокации и скорости создания новых белых объектов. Минусы: накладные расходы на защитную преграду записи оставались высокими, поскольку мы по-прежнему изменяли указатели внутри существующих (часто уже просканированных) черных объектов с той же скоростью; пул не решал затрат на выполнение барьера при обновлении указателей.
Третье рассматриваемое решение: Мы переработали граф, чтобы использовать целые индексы в большом срезе вместо прямых указателей для отношений между узлами. Плюсы: целочисленные присваивания не являются записями указателей, полностью обходя механизм защитной преграды записи и устраняя связанные затраты на процессор во время маркировки. Минусы: это требовало реализации ручного управления памятью для среза (обработка дыр, компактизация) и делало код менее идиоматичным и сложнее для поддержки.
Выбранное решение: Мы использовали подход на основе индексов для основного графа с высокой сменой, сохраняя указатели для статической метаданной. Это напрямую устранило горячий путь защитной преграды записи, сохраняя семантику связности графа.
Результат: Задержка при сборке мусора уменьшилась на 90%, с 15 мс до 1,5 мс, а общая пропускная способность увеличилась на 40% благодаря снижению работы по помощи сборке мусора, отнимающей процессор у мутаторов.
Почему защитная преграда записи затеняет объект, на который указывает, а не объект, который модифицируется?
Кандидаты часто ошибочно предполагают, что барьер должен отмечать исходный объект (тот, в который записывают) как нуждающийся в повторной проверке. Однако исходный объект уже либо серый, либо черный; если он черный, повторная проверка потребует много ресурсов и учета всех его исходящих указателей. В то же время затенение цели (нового значения указателя) в серый цвет немедленно удовлетворяет инварианту триколорности: если исходный объект черный и цель была белой, то связь становится черной к серой, что безопасно. Это различие крайне важно, так как оно минимизирует работу (в очередь ставится только новая цель), а не требует повторной проверки потенциально больших исходных объектов.
Как защитная преграда записи взаимодействует с аллокациями в стеке и почему могут понадобиться повторные проверки стеков?
Хотя защитные преграды записи главным образом перехватывают записи указателей в кучу, Go также должен обрабатывать указатели из стеков в кучу. Если горутина записывает указатель на белый объект кучи в черный фрейм стека, защитная преграда выполняется, чтобы затенить цель. Однако поскольку стеки могут расти, сокращаться и копироваться, поддержание точных черных/белых состояний для каждого слота стека является сложной задачей. Go решает это, рассматривая стеки как корни, которые могут потребовать повторной проверки в конце фазы маркировки, если они были активны во время маркировки. Кандидаты часто упускают, что повторная проверка стеков является необходимой мерой, когда защитные преграды на стеках не могут гарантировать инвариант из-за конкурентного выполнения, и что эта последняя фаза остановки системы обычно коротка, но важна для корректности.
В чем разница между защитной преградой записи Дейкстры и защитной преградой записи Юаса, и какую из них использует Go?
Защитная преграда Дейкстры затеняет целевой объект, когда указатель устанавливается (черный мутатор, белая цель), предотвращая существование связи черный-к-белому. Защитная преграда Юаса, наоборот, фиксирует старое значение указателя, которое переписывается, и затеняет его, сохраняя свойство "снимка-вовремя". Go использует гибридную защитную преграду Дейкстры, так как это проще и сразу же обеспечивает сильный инвариант триколорности, хотя она может вызывать плавающий мусор, если белый объект становится недостижимым сразу после затенения. Кандидаты часто путают это или предполагают, что Go использует Юаса из-за его консервативного обращения со стеком, но понимание выбора Дейкстры объясняет, почему барьера Go синхронна с записью, а не основана на логировании.