Проверяет понимание влияния аллокаций и “мусора” на производительность сервиса.
GC в Go автоматически очищает память, когда объектов на куче становится много. Чем больше вы создаёте временных объектов, тем чаще и дольше будет работать GC. Больше всего на GC влияют частые аллокации, большие срезы, строки и создание новых структур в горячих участках.
Go использует сборщик мусора (GC), чтобы освобождать память объектов, которые больше недостижимы. На высоком уровне:
программа выделяет объекты (часть уходит в heap),
GC периодически отмечает “живые” объекты,
недостижимые — освобождаются.
GC влияет на:
latency (паузы и дополнительная работа),
CPU (часть времени уходит на сборку).
Что сильнее всего увеличивает нагрузку на GC:
Частые аллокации в горячих циклах
Например, создание новых []byte/map/struct на каждый запрос.
Конкатенация строк в цикле
Часто создаёт новые строки и временные буферы.
json.Marshal/Unmarshal на больших структурах
Генерирует много временных объектов.
Большие временные срезы
Даже если быстро освобождаются, GC должен их “заметить” и убрать.
Как уменьшать влияние:
переиспользовать буферы (sync.Pool) для []byte (с осторожностью),
избегать лишних fmt.Sprintf в горячем коде,
уменьшать количество временных структур,
использовать билдеры (strings.Builder) для строк.
Вывод: чем меньше лишних аллокаций, тем ниже давление на GC и стабильнее latency под нагрузкой.
