nick152 Jun 30 at 11:23

Разбираемся в сборщике мусора Go: просто и с гофером

Medium

3 min

3.8K

Go *

From sandbox

+12

Comments 11

JuliaEva Jun 30 at 12:34

Написано просто и доступно, даже для человека, только начинающего свой путь в Go. Спасибо за статью! Иллюстрации крутые, гофер милашка☺️

ExternalWayfarer Jul 7 at 15:43

Иллюстрации - самое обычное нейрохрючево. Я так устал уже от этой срани везде, а на хабре вообще практически ни одна статья без них не обходится.

JuliaEva Jul 7 at 17:25

Ответ один - не читайте статьи на Хабре😉

В официальной документации нет иллюстраций - читайте ее вместо того чтобы выливать свой негатив на действительно достойные статьи и чужое мнение! Всего доброго👌🏻

evgeniy_kudinov Jun 30 at 15:59

3. Меньше аллокаций
Избегайте интерфейсов, если они не нужны, — они создают лишние объекты.

Про какие лишние объекты идет речь? Как то связано с выделением памяти?

nick152 Jun 30 at 19:02

Привет! Спасибо за вопрос 🙌
Если коротко — да, при работе с интерфейсами часто происходит выделение в куче, и это даёт дополнительную нагрузку на сборщик мусора (GC). А теперь подробнее:

Когда ты присваиваешь значение переменной интерфейсного типа, например:

var x interface{} = 123

Go "упаковывает" значение внутрь интерфейсной структуры, в которой хранятся:

указатель на само значение,
и указатель на "тип" (таблицу методов и прочую инфу).

Если само значение изначально лежало на стеке, но ты передаёшь его как interface{}, Go переместит его в кучу — на случай, если интерфейс переживёт текущую функцию. Это называется escape to heap.

func makeIt() interface{} {
    x := 42
    return x // x убегает в кучу!
}

Хотя x — просто int, Go не уверен, насколько долго будет жить interface{}, поэтому играет безопасно — делает аллокацию в куче.

Вот откуда берутся "лишние объекты" — это такие вот маленькие аллокации, которых можно было бы избежать, если бы использовали конкретный тип вместо интерфейса.
Хочешь убедиться? Скомпилируй этот код с анализом побега:

go build -gcflags="-m" main.go

И ты увидишь:

./main.go:9:9: x escapes to heap

Так что совет "избегайте интерфейсов без необходимости" — это не про стиль кода, а вполне практичная вещь: меньше аллокаций = меньше работы для GC = быстрее программа.

Надеюсь, помог

allishappy Jul 1 at 07:21

Теперь даже комменты ИИ пишут...

yerch74 Jul 1 at 16:10

А разве есть разница? Как по мне, главное что есть ответ на вопрос. Статья очень неплохая

evgeniy_kudinov Jul 2 at 17:37

Скрытый текст

Извините не удержался)

nick152 Jul 2 at 18:07

ИИ помог сформулировать мои мысли, чтобы было понятно другому, не вижу в этом ничего плохого 😉

В любом случае благодарен любому комментарию

Hidarikikino Jul 3 at 15:18

потому что перечитал кучу материалов про сборщик мусора (GC) в Go

Было здорово увидеть ссылки на эти материалы

nick152 Jul 3 at 18:26

Самая популярная статья на хабре, которая подробно объясняет как все устроено под капотом (но сложновато читается, как минимум для меня)
https://habr.com/ru/companies/avito/articles/753244/
Ну и конечно оф.документация (но опять таки я плохо знаю иглиш, мне было тяжело читать)
https://tip.golang.org/doc/gc-guide
есть еше статья на хабре про gc
https://habr.com/ru/articles/742402/
Если покопаться, то можно еще полезные статьи найти как можно пооптимизировать приложение и как gc и runtime в этом участвуют.

В моей статье не рассказывается подробно как все устроено под капотом, здесь цель была, чтобы было легко понять сам принцип работы новичку или человеку, который переходит на го