Память и GC

Разработчик утверждает: «Если функция возвращает указатель на локальную переменную, эта переменная всегда размещается в куче». Как уточнить это утверждение с точки зрения escape analysis Go?

В сервисе после увеличения GOGC снизилась загрузка CPU, но выросло потребление памяти. Каким механизмом объясняется этот компромисс?

Разбор последствий: почему две структуры одинакового размера могут по-разному влиять на паузы и загрузку GC?

В приложении число короткоживущих объектов резко выросло, но объём живой памяти почти не изменился. Почему производительность Go может заметно ухудшиться?

В веб-сервисе после возврата небольшого среза из большого буфера память не освобождается. Какой механизм Go объясняет это поведение?

Разберите, что происходит с памятью при последовательном росте среза через append без заранее заданной вместимости.

В Go-сервисе при резком росте скорости аллокаций горутины начинают тратить CPU на маркировку объектов. Каким механизмом сборщик мусора переносит часть своей работы на приложение?

Как наличие финализатора меняет момент освобождения объекта в Go?

В профиле Go-сервиса видно, что при большом числе записей указателей растёт время GC. Как механизм write barrier объясняет этот эффект?

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

Определите, сможет ли сборщик мусора Go освободить объекты после завершения makeCycle, несмотря на взаимные ссылки.

package main

import "runtime"

type Node struct {
    next *Node
    data [1024]byte
}

func makeCycle() {
    a := new(Node)
    b := new(Node)
    a.next = b
    b.next = a
    runtime.KeepAlive(a)
}

func main() {
    makeCycle()
    runtime.GC()
}

После того как сборщик мусора освободил большую часть объектов, RSS процесса почти не уменьшился. Каким механизмом Go объясняет такое поведение?

В профиле аллокаций после передачи крупных значений в any появились новые аллокации. Как определить, что их вызывает упаковка значения в интерфейс?

Команда снизила число аллокаций через sync.Pool, но после сборки мусора выигрыш исчезает. Какой механизм это объясняет?

Оцените, какой из массивов создаёт меньшую нагрузку на маркировку GC при сопоставимом размере данных. Объясните, какую роль играет наличие указателей в типе.

package main

import "runtime"

type Bytes struct {
    data [1024]byte
}

type Ptrs struct {
    data [128]*byte
}

func main() {
    b := make([]Bytes, 10_000)
    p := make([]Ptrs, 10_000)
    runtime.KeepAlive(b)
    runtime.KeepAlive(p)
}

Объясните механизм: как Go увеличивает стек горутины при углублении вызовов и почему это не равно последовательной heap-аллокации каждого локального значения?

Профиль аллокаций показывает множество очень мелких объектов без указателей: какой механизм Go может снизить накладные расходы на их размещение?

В обработчике запроса разработчик вызывает принудительную сборку мусора после каждой операции. Как это обычно влияет на задержку и загрузку CPU?

В функции создают пустой срез с большой заранее заданной вместимостью, но фактически добавляют лишь несколько элементов. Что произойдёт с памятью и почему длина среза не отражает стоимость такой аллокации?

На машине с тем же объёмом данных увеличение GOMAXPROCS сократило длительность GC, но ухудшило задержки запросов. Каким механизмом это объясняется?