Goのクロージャの性質を理解できない

Question

実現したいこと

func later() func(string) string {
	var store string
	return func(next string) string {
		a := store
		store = next
		return a

func main() {
	b := later()
	fmt.Println(b("あ"))  // => ""
	fmt.Println(b("い"))  // => "あ"
	fmt.Println(b("う"))  // => "い"
}

知りたいこと

このコードの場合、変数storeがクロージャに属する変数として何らかの形で参照され続ける限り破棄されないという性質を持っているということらしいのですが、どういう仕組みで上記のような結果になるのでしょうかご教授お願いします！

Answer 1

-gcflags "-m -l"をつけてビルドすると何が起こっているのかヒントが見れます。

>go build -gcflags "-m -l"
# closure
.\main.go:7:14: leaking param: next
.\main.go:6:6: moved to heap: store
.\main.go:7:9: func literal escapes to heap
.\main.go:16:13: ... argument does not escape
.\main.go:16:15: b("あ") escapes to heap
.\main.go:17:13: ... argument does not escape
.\main.go:17:15: b("い") escapes to heap
.\main.go:18:13: ... argument does not escape
.\main.go:18:15: b("う") escapes to heap

それぞれのメッセージの意味は以下の通り。

leaking param

関数が終わっても変数が生き続けるけど、メモリリークではありません。

move to heap

変数はヒープメモリに退避されました。

func literal escapes to heap

関数リテラルはヒープメモリに退避されました。

argument does not escape

関数に渡された引数は退避されません。

関数 escapes to heap

関数の戻り値はヒープメモリに退避します。

結論

• 関数リテラル＝クロージャーの中で親スコープのstoreにアクセスしているのを発見したのでヒープに退避しましたということ。
• ヒープに退避された場合、だれかが参照を残している限り破棄されずに保持されます。
• つまり、b変数のスコープアウトが発生すれば芋づる式にヒープに退避されたものはガベージコレクタによって破棄されます。

Comments

[noa-1129]

later関数の戻り値に指定したクロージャ(無名関数)内で変数storeを参照することで一旦ヒープメモリに退避することで保持、main関数で出力されている文字列はlater関数の戻り値である無名関数で変数storeに代入、参照したものとして返しているので出力結果が一つづつずれて表示されているという解釈であっているでしょうか？

[nobonobo]

はい。あってると思います！