Maison > développement back-end > Golang > ​Question d'entretien avec Golang : parler brièvement de l'évasion de la mémoire ?

​Question d'entretien avec Golang : parler brièvement de l'évasion de la mémoire ?

藏色散人
Libérer: 2021-04-16 10:02:41
avant
1856 Les gens l'ont consulté

Ce qui suit est une introduction aux questions d'entretien golang de la colonne du didacticiel golang : Parlez brièvement de l'évasion de la mémoire ? , j'espère que cela sera utile aux amis dans le besoin !

​Question d'entretien avec Golang : parler brièvement de l'évasion de la mémoire ?

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 escape
Copier après la connexion
  • ./main.go:8:10: new(A) escapes to heap Description new(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 escape Description b La 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 heap Description c Échappement des variables. Les variables imprimées via fmt.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 .

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:segmentfault.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal