Golang中defer、return、返回值之間執行順序的坑
Golang中defer、return、返回值之間執行順序的坑
原文連結:https://studygolang.com/articles/4809
Go語言中延遲函式defer充當著 cry...catch 的重任,使用起來也非常簡便,然而在實際應用中,很多gopher並沒有真正搞明白defer、return和返回值之間的執行順序,從而掉進坑中,今天我們就來揭開它的神祕面紗!
先來執行下面兩段程式碼:
A. 無名返回值的情況
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
fmt.Println( "defer1:" , i) // 列印結果為 defer: 1
|
B. 有名返回值的情況
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
先來假設出結論,幫助大家理解原因:
-
多個defer的執行順序為“後進先出”;
-
defer、return、返回值三者的執行邏輯應該是:return最先執行,return負責將結果寫入返回值中;接著defer開始執行一些收尾工作;最後函式攜帶當前返回值退出。
如何解釋兩種結果的不同:
上面兩段程式碼的返回結果之所以不同,其實從上面第2條結論很好理解。
a()int 函式的返回值沒有被提前聲名,其值來自於其他變數的賦值,而defer中修改的也是其他變數,而非返回值本身,因此函式退出時返回值並沒有被改變。
b()(i int) 函式的返回值被提前聲名,也就意味著defer中是可以呼叫到真實返回值的,因此defer在return賦值返回值 i 之後,再一次地修改了 i 的值,最終函式退出後的返回值才會是defer修改過的值。
C. 下面我們再來看第三個例子,驗證上面的結論:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
雖然 c()*int 的返回值沒有被提前宣告,但是由於 c()*int 的返回值是指標變數,那麼在return將變數 i 的地址賦給返回值後,defer再次修改了 i 在記憶體中的實際值,因此函式退出時返回值雖然依舊是原來的指標地址,但是其指向的記憶體實際值已經被成功修改了。
即,我們假設的結論是正確的!