go語言局部變量分配在棧還是堆

一個問題引發(fā)的思考？
如下go語言代碼

package main

func foo(m0 int) (*int) {
  var m1 int = 11;
  return &m1
}

func main() {
  m := foo(100)
  println(*m)
}

編譯運行：

$ go build main.go && ./main 
11

竟然沒有出現(xiàn)任何編譯錯誤。
熟悉C/C++語言的同學(xué)，立馬就能看出這個程序是存在"問題"的，即函數(shù)foo把局部變量m1的地址給返回了，當(dāng)函數(shù)foo返回的時候，m1的地址是會消亡的，這個代碼有很嚴(yán)重的問題，一般的C/C++編譯器都會給出警告錯誤：

$ cat main.c 
#include <stdio.h>

int * foo(int m0) {
  int m1 = 11;
  return &m1;
}

int main() {
  int * m = foo(100);
  printf("%d\n", *m);
}
$
$
$ gcc main.c 
main.c:8:11: warning: address of stack memory associated with local variable 'm1' returned [-Wreturn-stack-address]
  return &m1;
          ^~
1 warning generated.

如上C/C++編譯器明確給出了警告，foo把一個局部變量的地址返回了；反而高大上的go沒有給出任何警告，難道是go編譯器識別不出這個問題嗎？
答案不是的，參考go FAQ里面的一段話：

How do I know whether a variable is allocated on the heap or the stack?

From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.

The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.

In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

意思是說go語言編譯器會自動決定把一個變量放在棧還是放在堆，編譯器會做逃逸分析(escape analysis)，當(dāng)發(fā)現(xiàn)變量的作用域沒有跑出函數(shù)范圍，就可以在棧上，反之則必須分配在堆。
go語言聲稱這樣可以釋放程序員關(guān)于內(nèi)存的使用限制，更多的讓程序員關(guān)注于程序功能邏輯本身。

個人覺得這是扯淡，屬于自作主張的小聰明，非常不喜歡這個設(shè)計。還是C/C++的邏輯非常清楚：簡單邏輯是，聲明的局部變量分配在棧，通過動態(tài)申請(malloc, new)的內(nèi)存在堆里。

不爽歸不爽，既然go語言這么實踐了，我們還是來舉證一下這個例子：

$ cat main.go
package main

func foo(m0 int) (*int) {
  var m1 int = 11;
  var m2 int = 12; 
  var m3 int = 13; 
  var m4 int = 14; 
  var m5 int = 15; 

  println(&m0, &m1, &m2, &m3, &m4, &m5)
  println(&m0, &m1, &m2, &m3, &m4, &m5)
  println(&m0, &m1, &m2, &m3, &m4, &m5)
  println(&m0, &m1, &m2, &m3, &m4, &m5)
  println(&m0, &m1, &m2, &m3, &m4, &m5)

  return &m3
}

func main() {
  m := foo(100)
  println(*m)
}
$
$ go tool compile -m main.go |more
main.go:16:10: &m3 escapes to heap
main.go:6:7: moved to heap: m3
main.go:10:11: foo &m0 does not escape
main.go:10:16: foo &m1 does not escape
...
$
$ go build main.go && ./main 
0xc420041f58 0xc420041f38 0xc420041f30 0xc420012068 0xc420041f28 0xc420041f20
0xc420041f58 0xc420041f38 0xc420041f30 0xc420012068 0xc420041f28 0xc420041f20
0xc420041f58 0xc420041f38 0xc420041f30 0xc420012068 0xc420041f28 0xc420041f20
0xc420041f58 0xc420041f38 0xc420041f30 0xc420012068 0xc420041f28 0xc420041f20
0xc420041f58 0xc420041f38 0xc420041f30 0xc420012068 0xc420041f28 0xc420041f20
13

可以看出同樣定義的局部變量m0, m1, .... m5，他們的的地址是有差異的：m0作為傳入?yún)?shù)是分配在棧上，m1, m2, m4, m5也分配在棧上的連續(xù)地址，而m3的地址卻在堆上，因為編譯器分析出m3變量有逃逸行為。

我們再看一下編譯器生成的匯編碼：

var m1 int = 11;
  0x003e 00062 (/.../src/main/main.go:4) MOVQ  $11, "".m1+40(SP)
var m2 int = 12;
  0x0047 00071 (/.../src/main/main.go:5) MOVQ  $12, "".m2+32(SP)
var m3 int = 13;
  0x0050 00080 (/.../src/main/main.go:5) LEAQ  type.int(SB), AX
  0x0057 00087 (/.../src/main/main.go:6) MOVQ  AX, (SP)
  0x005b 00091 (/.../src/main/main.go:6) PCDATA  $0, $0
  0x005b 00091 (/.../src/main/main.go:6) CALL  runtime.newobject(SB)
  0x0060 00096 (/.../src/main/main.go:6) MOVQ  8(SP), AX
  0x0065 00101 (/.../src/main/main.go:6) MOVQ  AX, "".&m3+288(SP)
  0x006d 00109 (/.../src/main/main.go:6) MOVQ  $13, (AX)
var m4 int = 14;
  0x0074 00116 (/.../src/main/main.go:7) MOVQ  $14, "".m4+24(SP)
var m5 int = 15;
  0x007d 00125 (/.../src/main/main.go:8) MOVQ  $15, "".m5+16(SP)

看到對m3的處理調(diào)用了庫函數(shù)runtime.newobject(...)，所以把m3存放在堆中。

看來確實是go語言會根據(jù)局部變量有沒有發(fā)生逃逸行為來自動決定一個局部變量是分配在棧，還是分配在堆。

對于動態(tài)new出來的局部變量，go語言編譯器也會根據(jù)是否有逃逸行為來決定是分配在堆還是棧，而不是直接分配在堆中。

$ cat main.go
package main

func foo(m0 * int) (*int) {
  var m1 * int = new(int);
  var m2 * int = new(int);
  var m3 * int = new(int);
  var m4 * int = new(int);
  var m5 * int = new(int);

  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)
  println(m0, m1, m2, m3, m4, m5)

  return m3
}

func main() {
  n := 100
  m := foo(&n)
  println(*m)
}
$
$
$ go tool compile -m main.go |more
main.go:6:21: new(int) escapes to heap
main.go:3:22: foo m0 does not escape
main.go:4:21: foo new(int) does not escape
main.go:5:21: foo new(int) does not escape
main.go:7:21: foo new(int) does not escape
main.go:8:21: foo new(int) does not escape
main.go:29:12: main &n does not escape
$
$ go build main.go && ./main 
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0xc420041f60 0xc420041f28 0xc420041f20 0xc420012068 0xc420041f18 0xc420041f30
0

和前面例子一樣，m0作為參數(shù)分配在棧中，而 m1, m2, m4, m5也是分配在棧中，盡管他們都是通過new動態(tài)分配出來的，只有m3分配在堆中，原因是m3有逃逸行為。

結(jié)論就是一個函數(shù)內(nèi)局部變量，不管是不是動態(tài)new出來的，它會被分配在堆還是棧，是由編譯器做逃逸分析之后做出的決定。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 1. Java基礎(chǔ)部分 基礎(chǔ)部分的順序：基本語法，類相關(guān)的語法，內(nèi)部類的語法，繼承相關(guān)的語法，異常的語法，線程的語...
    子非魚_t_閱讀 34,623評論 18贊 399
  • JVM內(nèi)存模型Java虛擬機(Java Virtual Machine=JVM)的內(nèi)存空間分為五個部分，分別是： ...
    光劍書架上的書閱讀 2,772評論 2贊 26
  • 原文地址：C語言函數(shù)調(diào)用棧(一)C語言函數(shù)調(diào)用棧(二) 0 引言 程序的執(zhí)行過程可看作連續(xù)的函數(shù)調(diào)用。當(dāng)一個函數(shù)執(zhí)...
    小豬啊嗚閱讀 4,956評論 1贊 19
  • 讀到The Go Programming Language的2.3.2指針一節(jié)，我剛在驚訝Go中居然有和C這么像的...
    海豹激凸隊閱讀 1,023評論 0贊 0
  • 我突然睡不著，不知道為什么。 不知道是不是最近壓力大，還是……。最近感覺自己真的好像過上了那種日子，整天就在書桌上...
    減肥的女孩閱讀 377評論 0贊 0

友情鏈接更多精彩內(nèi)容