Стек и куча в Go

Растущий стек

Стартует стек горутины крошечным: в исходниках рантайма stackMin = 2048, две тысячи сорок восемь байт. Кончилось место - рантайм берёт вдвое больший кусок, копирует туда кадры и правит указатели внутри них. В stack.go это строка newsize := oldsize * 2.

Удвоения идут до потолка maxstacksize, в proc.go он равен 1000000000 байт на 64-битной системе и 250000000 на 32-битной. В моём падении рантайм напечатал границы стека: 0xc020080000 и 0xc040080000, разница 0x20000000 - это 512 МиБ. Следующее удвоение дало бы 1073741824 байта, что больше миллиарда, потолок и сработал.

// Два следствия. Первое: переполнение стека это fatal error, а не паника, поэтому recover не поймает и отложенные функции не отработают. У меня defer с печатью глубины так и не выполнился. Второе: с версии 1.19 стартовый размер рантайм подстраивает под наблюдаемое среднее, так что 2 КБ это нижняя граница, а не константа навсегда.

рост стека

новый кусок вдвое больше плюс копирование кадров

fatal error

падение без паники: recover и defer не работают

Почему предвыделение это не вкусовщина

Замерил append: собирал слайс из 1000 элементов, начиная с nil, и печатал вместимость на каждом перевыделении. Вышло так: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 848, 1280. Двенадцать перевыделений, и всего скопировано 1871 элемент, чтобы уложить 1000.

То есть почти двойная работа на ровном месте. make([]int, 0, 1000) убирает её целиком: одно выделение, ноль копирований. Заодно из цифр видно, что удвоение не вечное - после 256 элементов новая вместимость считается как старая плюс четверть от суммы старой и 768, а потом округляется вверх до размерного класса аллокатора. Отсюда 848 вместо ожидаемой тысячи: 512 + (512 + 768) / 4 = 832, и округление до класса дало 848.

// Побочный эффект, который ловят руками: при перевыделении массив переезжает на новое место. Указатель на элемент, взятый до append, продолжает смотреть в старый массив, и запись по нему пропадает бесследно.

предвыделение

make([]T, 0, n) - одно выделение вместо череды

размерный класс

аллокатор округляет запрос до ближайшего размера

sync.Pool: положил, собрал мусор, не нашёл

Опыт в три строки. Кладу объект в sync.Pool и тут же беру - вернулся тот же самый, сравнение указателей дало true. Кладу обратно, зову runtime.GC() - это принудительный запуск сборщика мусора, garbage collector, - и беру снова: вернулся новый, сравнение дало false.

Из этого следует всё правило пользования. sync.Pool - склад временных объектов, обычно буферов: вместо аллокации на каждый запрос берёшь готовый и возвращаешь после. Сборщику меньше работы. Но склад чистят при каждой сборке, поэтому держать там что-то ценное нельзя: это кэш без гарантий, а не хранилище.

// Вторая обязательная привычка: взял объект - приведи его в чистое состояние, для буфера это buf = buf[:0]. Иначе одному пользователю приедет хвост данных другого, и разговор пойдёт уже не про производительность.

sync.Pool

склад временных объектов, чистится при сборке

очистка при взятии

buf = buf[:0], иначе утекут чужие данные

Утечки при живом сборщике

Замер, который лечит веру в магию. Выделил 100 МиБ, сделал small := big[:10], обнулил big, позвал сборку. HeapAlloc после этого - ровно 100,0 МиБ. Повторил, скопировав нужные десять байт в отдельный слайс: 0,0 МиБ.

Срез это указатель в массив, длина и вместимость. Пока жив срез, жив весь массив, в который он смотрит, даже если тебе оттуда нужны десять байт из ста мегабайт. Сборщик тут ни при чём: объект достижим, значит живой.

// Тот же класс ошибок: глобальная мапа, которая только растёт, кэш без вытеснения, горутина, заблокированная навсегда вместе со всем, что она держала. Сборщик убирает недостижимое, а не ненужное - разницу между этими словами и проверяет вопрос.

логическая утечка

объект достижим, хотя давно не нужен

удержание массива срезом

срез на 10 байт держит 100 МиБ живыми

Как отвечать: «Что происходит при нехватке стека горутины и зачем sync.Pool?»

Стек горутины стартует с двух килобайт и растёт динамически: когда места не хватает, рантайм выделяет вдвое больший кусок, копирует туда кадры и правит указатели внутри них. Растёт он до потолка в миллиард байт на 64-битной системе - я это проверял бесконечной рекурсией, рантайм печатает goroutine stack exceeds 1000000000-byte limit и падает. Причём падает именно с fatal error, а не паникой: recover не поможет, отложенные функции не отработают. Стек вообще дешевле кучи: выделение там сдвиг указателя, освобождение бесплатное, сборщику делать нечего. sync.Pool решает соседнюю задачу - переиспользование временных объектов, обычно буферов: вместо аллокации на каждый запрос берём готовый из пула и возвращаем обратно, и сборщик получает меньше работы. Две оговорки обязательны. Первая: пул чистится при каждой сборке мусора, я это проверял - до runtime.GC возвращается тот же объект, после уже новый, поэтому ничего ценного там хранить нельзя. Вторая: взятый объект надо привести в чистое состояние, иначе в ответ приедет хвост данных предыдущего запроса. И беру я пул только после профиля, когда аллокации действительно в горячем пути.

Сильный ответ: механизм роста стека назван точно, вместе с потолком и с тем, что переполнение непоправимо. Разница цены стека и кучи объяснена через механику, а по sync.Pool даны обе критичные оговорки и условие применения - после профиля, а не по привычке.

На чём валят

• −Думают, что стек горутины фиксирован, как у потока операционной системы.
• −Надеются поймать переполнение стека через recover. Это fatal error, defer тоже не отработает.
• −Кладут в sync.Pool то, что нельзя потерять при сборке мусора.
• −Берут объект из пула, не очистив, и утаскивают в ответ чужие данные.
• −Держат срезом на десять байт стомегабайтный массив вместо копирования нужного куска.