Question
Connaissez-vous l'évasion mémoire de Golang ? Dans quelles circonstances se produit un évasion de mémoire ?
Comment répondre
golang程序变量 contiendra un ensemble de données de vérification pour prouver si l'ensemble de son cycle de vie est entièrement connu au moment de l'exécution. Si la variable réussit ces vérifications, elle peut être allouée dans 栈上. Sinon, dites simplement que c'est 逃逸 et que ça doit être dans 堆上分配.
Situations typiques qui peuvent provoquer la fuite de variables vers le tas :
- Renvoyer le pointeur de variable locale dans la méthode La variable locale aurait dû être Allouer sur la pile et désallouer sur la pile. Cependant, comme il est référencé en externe lors du retour, son cycle de vie est supérieur à celui de la pile et il déborde.
- Envoyer un pointeur ou une valeur avec un pointeur vers le canal. Au moment de la compilation, il n'y a aucun moyen de savoir quelle goroutine recevra les données sur le canal. Le compilateur n'a donc aucun moyen de savoir quand la variable sera publiée.
- Stockez un pointeur ou une valeur avec un pointeur sur une tranche. Un exemple typique est []*string. Cela provoque la fuite du contenu de la tranche. Bien que le tableau derrière lui puisse être alloué sur la pile, la valeur à laquelle il fait référence doit être sur le tas. Le tableau derrière la
- slice est réaffecté car sa capacité (cap) peut être dépassée lors de l'ajout. L'endroit où la tranche est initialisée peut être connu au moment de la compilation, et il sera initialement alloué sur la pile. Si le stockage derrière la tranche doit être étendu en fonction des données d'exécution, il sera alloué sur le tas.
- Appeler une méthode sur un type d'interface. L'appel des méthodes sur les types d'interface est distribué dynamiquement - l'implémentation réelle de la méthode ne peut être connue qu'au moment de l'exécution. Imaginez une variable r de type io.Reader. L'appel de r.Read(b) entraînera l'échappement de la valeur de r et du stockage derrière la tranche b, ils seront donc alloués sur le tas.
Exemple
- Utilisons un exemple pour approfondir notre compréhension. Ensuite, essayons de vérifier la situation d'évasion via
go build -gcflags=-m.
package main
import "fmt"
type A struct {
s string
}
// 这是上面提到的 "在方法内把局部变量指针返回" 的情况
func foo(s string) *A {
a := new(A)
a.s = s
return a //返回局部变量a,在C语言中妥妥野指针，但在go则ok，但a会逃逸到堆
}
func main() {
a := foo("hello")
b := a.s + " world"
c := b + "!"
fmt.Println(c)
}Copier après la connexion
Exécutiongo build -gcflags=-m main.go
go build -gcflags=-m main.go
# command-line-arguments
./main.go:7:6: can inline foo
./main.go:13:10: inlining call to foo
./main.go:16:13: inlining call to fmt.Println
/var/folders/45/qx9lfw2s2zzgvhzg3mtzkwzc0000gn/T/go-build409982591/b001/_gomod_.go:6:6: can inline init.0
./main.go:7:10: leaking param: s
./main.go:8:10: new(A) escapes to heap
./main.go:16:13: io.Writer(os.Stdout) escapes to heap
./main.go:16:13: c escapes to heap
./main.go:15:9: b + "!" escapes to heap
./main.go:13:10: main new(A) does not escape
./main.go:14:11: main a.s + " world" does not escape
./main.go:16:13: main []interface {} literal does not escape
<autogenerated>:1: os.(*File).close .this does not escapeCopier après la connexion
-
./main.go:8:10: new(A) escapes to heapDescriptionnew(A)s'est échappé, conformément à la première des situations courantes mentionnées ci-dessus. -
./main.go:14:11: main a.s + " world" does not escapeDescriptionbLa variable ne s'échappe pas car elle n'existe qu'au sein de la méthode et sera recyclée à la fin de la méthode. -
./main.go:15:9: b + "!" escapes to heapDescriptioncÉchappement des variables. Les variables imprimées viafmt.Println(a ...interface{})s'échapperont toutes. Les amis intéressés peuvent vérifier pourquoi. - L'opération ci-dessus est en fait appelée analyse d'évasion. Dans le prochain article, je vous expliquerai comment utiliser une méthode plus délicate pour empêcher les variables de s'échapper. Il est pratique pour tout le monde de s'exhiber devant l'intervieweur .
