Réponse

Le compilateur Go applique un mécanisme d'analyse d'échappement : toutes les valeurs par défaut sont placées sur la pile, mais si une variable "quitte" la portée (par exemple, si un pointeur vers une variable locale est retourné), elle est automatiquement placée dans le tas (heap).

C'est important pour les performances :

• La pile est très rapide, se libère automatiquement, ne nécessite pas de GC.
• Le tas est plus coûteux (gestion de la mémoire, GC).

Le compilateur essaie de déterminer si un objet peut être placé sur la pile, mais s'il survit implicitement aux limites de la fonction, il est placé dans le tas.

Exemple avec échappement :

func NewPoint() *int {
    a := 42
    return &a // échappement vers le tas !
}

Exemple sans échappement :

func Sum(a, b int) int {
    c := a + b
    return c // sur la pile
}

Pour diagnostiquer le compilateur, utilisez go build -gcflags='-m' pour voir les détails :

go build -gcflags='-m' main.go

Question piège

"L'objet ira-t-il dans le tas si je retourne seulement sa valeur — et non un pointeur ?"

On pense souvent que toutes les valeurs retournées "vont dans le tas". En réalité, si une valeur (et non un pointeur) est retournée, la variable peut rester sur la pile.

Exemple :

func F() int {
    x := 10
    return x // allocation sur la pile, ne va pas dans le tas
}

Exemples d'erreurs réelles à cause de l'ignorance des subtilités du sujet

---

Histoire

Lors de la création massive de structures via une fonction de fabrique retournant des pointeurs vers des variables locales, la consommation de mémoire et la charge sur le GC ont fortement augmenté. Il s'est avéré que tous les objets partaient dans le tas à cause du retour d'un pointeur sur une variable locale, ce qui aurait pu être évité en retournant une valeur.

---

Histoire

Dans un microservice, à cause du passage de pointeurs entre goroutines et de leur retour de différentes fonctions, de nombreux objets "fuitaient" de la pile vers le tas, ce qui ralentissait le processus et causait des pauses fréquentes du GC.

---

Histoire

Un développeur a accidentellement enveloppé un tableau statique dans un slice à l'intérieur d'une fonction, retournait un pointeur sur le slice — et lors du test de charge a commencé à rencontrer des fuites de mémoire. Le diagnostic a montré que la variable ne "dépassait" pas les limites de la fonction, mais Go a erronément décidé de la placer dans le tas en raison d'une utilisation indirecte.