Сегодня я решил перевести для вас небольшую статью о внутренностях реализации так называемых замыканий или closures. В дополнение вы узнаете о том, как Go пытается автоматически определить, нужно ли использовать указатель/ссылку или значение в разных случаях. Понимание этих вещей позволит избежать ошибок. Да и просто все эти внутренности чертовски интересны, как мне кажется!

А еще я хотел бы пригласить вас на Golang Conf 2019, которая пройдет 7 октября в Москве. Я член программного комитета конференции, и мы с коллегами выбрали много не менее хардкорных и очень, очень интересных докладов. То, что я люблю!

Под катом передаю слово автору.

На Go вики есть страничка с названием «Частые ошибки». Любопытно, но в ней только один пример: неправильное использование переменных цикла вместе с горутинами (goroutines):

for _, val := range values {
  go func() {
    fmt.Println(val)
  }()
}

Этот код выведет последнее значение из массива values len(values) раз. Исправить код очень просто:

// assume the type of each value is string
for _, val := range values {
  go func(val string) {
    fmt.Println(val)
  }(val)
}

Этого примера достаточно, чтобы понять проблему и больше никогда не повторять ошибку. Но если вам интересно узнать подробности реализации, эта статья даст вам глубокое понимание как проблемы, так и решения.

Базовые вещи: передача по значению и передача по ссылке

В Go существует различие в передаче объектов по значению и по ссылке [1]. Начнем с примера 1 [2]:

func foobyval(n int) {
  fmt.Println(n)
}

func main() {
  for i := 0; i < 5; i++ {
    go foobyval(i)
  }

  time.Sleep(100 * time.Millisecond)
}

Ни у кого, скорее всего, нет сомнения, что в результате будут выведены значения от 0 до 4. Вероятно, в каком-то случайном порядке.

Давайте посмотрим на пример 2.

func foobyref(n *int) {
  fmt.Println(*n)
}

func main() {
  for i := 0; i < 5; i++ {
    go foobyref(&i)
  }

  time.Sleep(100 * time.Millisecond)
}

В результате будет выведено следующее:

5
5
5
5
5

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

А ответ — он прямо там, в спецификации языка Go. Спецификация гласит:

Переменные, объявленные в инициализирующем операторе, переиспользуются в каждом цикле.

Это означает, что, когда программа запущена, существует только один объект или кусок памяти для переменной i, а не создается новый для каждого цикла. Этот объект принимает новое значение на каждой итерации.

Давайте посмотрим на разницу в сгенерированном машинном коде [3] для цикла в примерах 1 и 2. Начнем с примера 1.

0x0026 00038 (go-func-byval.go:14)      MOVL    $8, (SP)
0x002d 00045 (go-func-byval.go:14)      LEAQ    "".foobyval·f(SB), CX
0x0034 00052 (go-func-byval.go:14)      MOVQ    CX, 8(SP)
0x0039 00057 (go-func-byval.go:14)      MOVQ    AX, 16(SP)
0x003e 00062 (go-func-byval.go:14)      CALL    runtime.newproc(SB)
0x0043 00067 (go-func-byval.go:13)      MOVQ    "".i+24(SP), AX
0x0048 00072 (go-func-byval.go:13)      INCQ    AX
0x004b 00075 (go-func-byval.go:13)      CMPQ    AX, $5
0x004f 00079 (go-func-byval.go:13)      JLT     33

Go-оператор превращается в вызов функции runtime.newproc. Механика этого процесса очень интересна, но оставим это для следующей статьи. Сейчас нас больше интересует, что происходит с переменной i. Она сохраняется в регистре AX, который затем передается по значению через стек в функцию foobyval [4] в качестве ее аргумента. «По значению» в данном случае выглядит как копирование значения регистра AX на стек. И изменение AX в дальнейшем не влияет на то, что передано в функцию foobyval.

А вот как выглядит пример 2:

0x0040 00064 (go-func-byref.go:14)      LEAQ    "".foobyref·f(SB), CX
0x0047 00071 (go-func-byref.go:14)      MOVQ    CX, 8(SP)
0x004c 00076 (go-func-byref.go:14)      MOVQ    AX, 16(SP)
0x0051 00081 (go-func-byref.go:14)      CALL    runtime.newproc(SB)
0x0056 00086 (go-func-byref.go:13)      MOVQ    "".&i+24(SP), AX
0x005b 00091 (go-func-byref.go:13)      INCQ    (AX)
0x005e 00094 (go-func-byref.go:13)      CMPQ    (AX), $5
0x0062 00098 (go-func-byref.go:13)      JLT     57

Код очень похож — с одной только, но очень важной, разницей. Сейчас в AX находится адрес i, а не её значение. Заметьте еще, что инкремент и сравнение для цикла делаются над (AX), а не AX. И далее, когда мы положим AX на стек, мы, получается, передаем в функцию адрес i. Изменение (AX) будет видно таким образом и в горутине.

Никаких сюрпризов. В конце концов, мы передаем указатель на число в функцию foobyref.
Во время работы цикл заканчивается быстрее, чем любая из созданных горутин начинает работать. Когда они начнут работать, у них будет указатель на ту самую переменную i, а не на копию. И какое же значение у i в этот момент? Значение 5. То самое, на котором у нас остановился цикл. И вот почему все горутины выводят 5.

Методы со значением VS методы с указателем

Похожее поведение можно наблюдать при создании горутин, которые вызывают какие-либо методы. На это указывает та же самая вики-страничка. Посмотрите на пример 3:

type MyInt int

func (mi MyInt) Show() {
  fmt.Println(mi)
}

func main() {
  ms := []MyInt{50, 60, 70, 80, 90}
  for _, m := range ms {
    go m.Show()
  }

  time.Sleep(100 * time.Millisecond)
}

Данный пример выводит элементы массива ms. В рандомном порядке, как мы и ожидали. Очень похожий пример 4 использует метод с указателем для метода Show:

type MyInt int

func (mi *MyInt) Show() {
  fmt.Println(*mi)
}

func main() {
  ms := []MyInt{50, 60, 70, 80, 90}
  for _, m := range ms {
    go m.Show()
  }

  time.Sleep(100 * time.Millisecond)
}

Попробуйте угадать, какой будет вывод: 90, напечатанное пять раз. Причина такая же, как и в более простом примере 2. Здесь проблема менее заметна из-за синтаксического сахара в Go при использовании методов с указателями. Если в примерах при переходе от примера 1 к примеру 2 мы сменили i на &i, здесь же вызов выглядит одинаково! m.Show() в обоих примерах, а поведение разное.

Не очень счастливое стечение двух особенностей Go, как мне кажется. Ничего в месте вызова не указывает на передачу по ссылке. И вам нужно будет посмотреть на реализацию метода Show, чтобы увидеть, как именно будет происходить вызов (а метод, конечно же, может быть в абсолютно другом файле или пакете).

В большинстве случаев данная фича полезна. Мы пишем более чистый код. Но здесь же передача по ссылке приводит к неожиданным эффектам.

Замыкания

Наконец-то мы подошли к замыканиям. Посмотрим на пример 5:

func foobyval(n int) {
  fmt.Println(n)
}

func main() {
  for i := 0; i < 5; i++ {
    go func() {
      foobyval(i)
    }()
  }

  time.Sleep(100 * time.Millisecond)
}

Он напечатает следующее:

5
5
5
5
5

И это несмотря на то, что i передается по значению в foobyval в замыкании. Аналогично примеру 1. Но почему? Давайте посмотрим на ассемблерное представление цикла:

0x0040 00064 (go-closure.go:14) LEAQ    "".main.func1·f(SB), CX
0x0047 00071 (go-closure.go:14) MOVQ    CX, 8(SP)
0x004c 00076 (go-closure.go:14) MOVQ    AX, 16(SP)
0x0051 00081 (go-closure.go:14) CALL    runtime.newproc(SB)
0x0056 00086 (go-closure.go:13) MOVQ    "".&i+24(SP), AX
0x005b 00091 (go-closure.go:13) INCQ    (AX)
0x005e 00094 (go-closure.go:13) CMPQ    (AX), $5
0x0062 00098 (go-closure.go:13) JLT     57

Код очень похож на пример 2: заметьте, что i представлен адресом в регистре AX. То есть мы передаем i по ссылке. И это несмотря на то, что вызывается foobyval. Тело цикла вызывает функцию используя runtime.newproc, но откуда берется эта функция?

Func1 создана компилятором, и она представляет собой замыкание. Компилятор выделил код замыкания в отдельную функцию и вызывает ее из main. Основная проблема данного выделения в том, как быть с переменными, которые замыкания используют, но которые явно не являются аргументами.

Вот как выглядит тело func1:

0x0000 00000 (go-closure.go:14) MOVQ    (TLS), CX
0x0009 00009 (go-closure.go:14) CMPQ    SP, 16(CX)
0x000d 00013 (go-closure.go:14) JLS     56
0x000f 00015 (go-closure.go:14) SUBQ    $16, SP
0x0013 00019 (go-closure.go:14) MOVQ    BP, 8(SP)
0x0018 00024 (go-closure.go:14) LEAQ    8(SP), BP
0x001d 00029 (go-closure.go:15) MOVQ    "".&i+24(SP), AX
0x0022 00034 (go-closure.go:15) MOVQ    (AX), AX
0x0025 00037 (go-closure.go:15) MOVQ    AX, (SP)
0x0029 00041 (go-closure.go:15) CALL    "".foobyval(SB)
0x002e 00046 (go-closure.go:16) MOVQ    8(SP), BP
0x0033 00051 (go-closure.go:16) ADDQ    $16, SP
0x0037 00055 (go-closure.go:16) RET

Здесь интересно, что у функции есть аргумент в 24(SP), который является указателем на int: взгляните на строчку MOVQ (AX), AX, которая берет значение, прежде чем передать его в foobyval. По сути func1 выглядит как-то так:

func func1(i *int) {
  foobyval(*i)
}

И цикл в main преобразуется в что-то такое:
for i := 0; i < 5; i++ {
  go func1(&i)
}

Получили эквивалент примеру 2, и это объясняет полученный вывод. Техническим языком мы бы сказали, что i является свободной переменной внутри замыкания и такие переменные захватываются по ссылке в Go.

Но всегда ли это так? На удивление, ответ “нет”. В некоторых случаях свободные переменные захватываются по значению. Вот вариация нашего примера:

for i := 0; i < 5; i++ {
        ii := i
        go func() {
                foobyval(ii)
        }()
}

Этот пример выведет 0, 1, 2, 3, 4 в случайном порядке. Но почему поведение здесь отличается от примера 5?

Оказывается, что данное поведение является артефактом эвристики, которую компилятор Go использует, когда работает с замыканиями.

Смотрим под капот

Если вы не знакомы с архитектурой компилятора Go, я рекомендую вам прочитать мои ранние статьи на эту тему: часть 1, часть 2.

Конкретное (в противовес абстрактному) синтаксическое дерево, которое получается при парсинге кода, выглядит так:

0: *syntax.CallStmt {
.  Tok: go
.  Call: *syntax.CallExpr {
.  .  Fun: *syntax.FuncLit {
.  .  .  Type: *syntax.FuncType {
.  .  .  .  ParamList: nil
.  .  .  .  ResultList: nil
.  .  .  }
.  .  .  Body: *syntax.BlockStmt {
.  .  .  .  List: []syntax.Stmt (1 entries) {
.  .  .  .  .  0: *syntax.ExprStmt {
.  .  .  .  .  .  X: *syntax.CallExpr {
.  .  .  .  .  .  .  Fun: foobyval @ go-closure.go:15:4
.  .  .  .  .  .  .  ArgList: []syntax.Expr (1 entries) {
.  .  .  .  .  .  .  .  0: i @ go-closure.go:15:13
.  .  .  .  .  .  .  }
.  .  .  .  .  .  .  HasDots: false
.  .  .  .  .  .  }
.  .  .  .  .  }
.  .  .  .  }
.  .  .  .  Rbrace: syntax.Pos {}
.  .  .  }
.  .  }
.  .  ArgList: nil
.  .  HasDots: false
.  }
}

Вызываемая функция представлена нодой FuncLit — константной функцией. Когда это дерево будет преобразовано в AST (абстрактное синтаксическое дерево), выделение этой константной функции в отдельно стоящую будет результатом. Это происходит в методе noder.funcLit, что живет в gc/closure.go.

Затем тайп чекер завершает трансформацию, и мы получаем следующее представление для функции в AST:

main.func1:
.   DCLFUNC l(14) tc(1) FUNC-func()
.   DCLFUNC-body
.   .   CALLFUNC l(15) tc(1)
.   .   .   NAME-main.foobyval a(true) l(8) x(0) class(PFUNC) tc(1) used FUNC-func(int)
.   .   CALLFUNC-list
.   .   .   NAME-main.i l(15) x(0) class(PAUTOHEAP) tc(1) used int

Обратите внимание, что передаваемое значение в foobyval — это NAME-main.i, то есть мы явно указываем на переменную из функции, которая оборачивает замыкание.

На данном этапе вступает в работу стадия компилятора по имени capturevars, то есть «захват переменных». Ее цель — решить, как захватить «закрытые переменные» (то есть свободные переменные, используемые в замыканиях). Вот комментарий из соответствующей функции компилятора, который также описывает эвристику:

// capturevars вызывается в отдельной фазе после всех проверок типов.
// Он решает, нужно ли захватывать переменную по значению или по ссылке.
// Мы используем захват по ссылке для значений <= 128 байт, которые больше не меняют значение после захвата (по сути константы).

Когда capturevars вызывается на примере 5, он решает, что переменная цикла i должна быть захвачена по ссылке, и добавляет соответствующий флаг addrtaken к ней. Это видно в AST выводе:

FOR l(13) tc(1)
.   LT l(13) tc(1) bool
.   .   NAME-main.i a(true) g(1) l(13) x(0) class(PAUTOHEAP) esc(h) tc(1) addrtaken assigned used int

Для переменной цикла не срабатывает эвристика выбора «по значению», так как переменная меняет свое значение после вызова (вспомните цитату из спецификации о том что переменная цикла переиспользуется на каждой итерации). Поэтому переменная i захватывается по ссылке.
В той вариации нашего примера, где у нас есть ii := i, ii не используется больше и поэтому захватывается по значению [5].

Таким образом, мы видим потрясающий пример наложения двух разных фич языка неожиданным образом. Вместо использования новой переменной на каждой итерации цикла, Go переиспользует ту же самую. Это, в свою очередь, ведет к срабатыванию эвристики и выбору захвата по ссылке, а это ведет к неожиданному результату. Go FAQ говорит, что данное поведение, возможно, ошибка при проектировании.

Данное поведение (не использовать новую переменную) — наверное, ошибка при проектировании языка. Возможно мы ее починим в следующих версиях, но из-за обратной совместимости мы не можем ничего сделать в Go версии 1.

Если вы в курсе проблемы, вы, скорее всего, не наступите на эти грабли. Но имейте в виду, что свободные переменные всегда могут быть захвачены по ссылке. Чтобы избежать ошибок, убедитесь, что только read-only переменные захватываются при использовании горутин. Это также важно из-за потенциальных проблем с дата-рейсами.

---

[1] Некоторые читатели заметили что, строго говоря, не существует понятия «передача по ссылке» в Go, т. к. все передается по значению, в том числе указатели. В данной статье, когда вы видите «передача по ссылке», я имею в виду «передача по адресу» и она в некоторых случаях явная (как например передача &n в функцию, которая ожидает *int), а в некоторых неявная, как в поздних частях статьи.

[2] Здесь и далее я использую time.Sleep как быстрый и грязный способ подождать завершения всех горутин. Без этого main завершится до того, как горутины начнут работать. Правильным способом сделать это было бы использование чего-нибудь типа WaitGroup или done канала.

[3] Ассемблерное представление для всех примеров из данной статьи получено с использованием команды go tool compile -l -S. Флаг -l отключает инлайнинг функций и делает ассемблерный код более читаемым.

[4] Foobyval не вызывется напрямую, так как вызов идет через go. Вместо этого адрес передается как второй аргумент (16(SP)) функции runtime.newproc, а аргументу для foobyval (i в данном случае) идут выше по стеку.

[5] В качестве упражнения добавьте ii = 10 в качестве последней строчки for цикла (после вызова go). Какой вы получили вывод? Почему?

Автор: Марко Кевац

Источник