Garbage Collection en Go
Fait partie de la section Programmation Orientée Objet du Journey GO de Coddy — leçon 23 sur 107.
Contrairement à des langages tels que le C ou le C++, Go gère automatiquement la gestion de la mémoire via le ramasse-miettes (GC). Vous n'avez pas besoin de libérer manuellement la mémoire lorsque vous avez fini de l'utiliser. Le runtime Go suit quelle mémoire est encore utilisée et récupère le reste.
Lorsque vous allouez de la mémoire en utilisant new(), make(), ou en créant des variables, le ramasse-miettes (garbage collector) de Go surveille ces allocations. Une fois qu'une valeur n'est plus accessible par aucune partie de votre programme, le GC libère automatiquement cette mémoire.
func createPerson() *Person {
p := &Person{Name: "Alice", Age: 30}
return p // p s'échappe vers le tas, le GC s'en occupera
}
func main() {
person := createPerson()
fmt.Println(person.Name)
// Lorsque person n'est plus utilisé, le GC récupère la mémoire
}Dans cet exemple, la structure Person est allouée sur le tas car elle est retournée par la fonction. Le compilateur de Go effectue une analyse d'échappement pour déterminer si une variable peut rester sur la pile ou doit être déplacée vers le tas. Le garbage collector gère uniquement la mémoire du tas.
Cette gestion automatique de la mémoire signifie que vous pouvez vous concentrer sur la création de votre application sans vous soucier des fuites de mémoire dues à des désallocations oubliées. Cependant, comprendre que le GC existe vous aide à écrire un code plus efficace en minimisant les allocations inutiles lorsque la performance est importante.
Défi
FacileConstruisons un gestionnaire de session qui démontre comment le ramasse-miettes (garbage collector) de Go gère la mémoire pour les objets qui s'échappent vers le tas (heap). Vous allez créer des sessions allouées dynamiquement et retournées par des fonctions, laissant le GC gérer leur cycle de vie.
Vous organiserez votre code sur deux fichiers :
session.go: Définissez une structureSessionavec les champsID(string),Username(string) etData(une tranche de chaînes de caractères - slice of strings). Créez une fonctionNewSessionqui prend un ID et un nom d'utilisateur, alloue une nouvelle Session sur le tas (en retournant un pointeur) et initialise la tranche Data comme vide. Ajoutez également une méthodeAddDataavec un récepteur de pointeur qui ajoute une chaîne à la tranche Data de la session, et une méthodeSummaryqui retourne une chaîne formatée affichant les détails de la session.main.go: Lisez les informations de session à partir de l'entrée, créez une session à l'aide de votre fonction constructeur, ajoutez-y quelques entrées de données et affichez le résumé de la session. Comme la session est créée à l'intérieur d'une fonction et retournée sous forme de pointeur, elle s'échappe vers le tas où le ramasse-miettes la gérera.
Les entrées suivantes seront fournies :
- Ligne 1 : ID de session
- Ligne 2 : Nom d'utilisateur
- Ligne 3 : Première entrée de données à ajouter
- Ligne 4 : Deuxième entrée de données à ajouter
Votre méthode Summary doit retourner une chaîne dans ce format :
Session [ID] for user [Username]
Data entries: [count]
- [entry1]
- [entry2]Par exemple, avec sess-001, alice, login et view_dashboard, votre sortie devrait être :
Session sess-001 for user alice
Data entries: 2
- login
- view_dashboardL'idée clé ici est que votre fonction NewSession crée une Session et retourne un pointeur vers celle-ci. Cela provoque l'« échappement » de la Session vers le tas plutôt que de rester sur la pile (stack), ce qui la rend éligible au ramasse-miettes une fois qu'il ne reste plus de références vers elle. Votre code n'a pas besoin de libérer manuellement cette mémoire — Go s'en occupe automatiquement.
Aide-mémoire
Go utilise le ramasse-miettes (garbage collection - GC) pour la gestion automatique de la mémoire. Vous n'avez pas besoin de libérer manuellement la mémoire.
Le ramasse-miettes suit les allocations de mémoire et récupère la mémoire qui n'est plus accessible par votre programme.
func createPerson() *Person {
p := &Person{Name: "Alice", Age: 30}
return p // p s'échappe vers le tas (heap), le GC le gérera
}
func main() {
person := createPerson()
fmt.Println(person.Name)
// Lorsque person n'est plus utilisé, le GC récupère la mémoire
}Le compilateur de Go effectue une analyse d'échappement (escape analysis) pour déterminer si une variable reste sur la pile (stack) ou se déplace vers le tas (heap). Les variables qui s'échappent vers le tas (comme les pointeurs retournés) sont gérées par le ramasse-miettes.
Le GC ne gère que la mémoire du tas, pas la mémoire de la pile. La mémoire de la pile est automatiquement libérée lorsqu'une fonction se termine.
Essayez vous-même
package main
import (
"bufio"
"fmt"
"os"
)
func main() {
reader := bufio.NewReader(os.Stdin)
// Lire l'ID de session
sessionID, _ := reader.ReadString('\n')
sessionID = sessionID[:len(sessionID)-1]
// Lire le nom d'utilisateur
username, _ := reader.ReadString('\n')
username = username[:len(username)-1]
// Lire la première entrée de données
data1, _ := reader.ReadString('\n')
data1 = data1[:len(data1)-1]
// Lire la deuxième entrée de données
data2, _ := reader.ReadString('\n')
data2 = data2[:len(data2)-1]
// TODO: Créer une nouvelle session en utilisant la fonction NewSession
// La session s'échappera vers le tas (heap) car nous retournons un pointeur
// TODO: Ajouter les entrées de données à la session en utilisant la méthode AddData
// TODO: Afficher le résumé de la session en utilisant la méthode Summary
fmt.Println("")
}
Cette leçon comprend un petit quiz. Commencez la leçon pour y répondre et suivre votre progression.
Toutes les leçons de Programmation Orientée Objet
1Fondamentaux de la POO en Go
Fichiers externesEspace de travail et Modules GoPackages et ImportsNoms exportés vs non exportésIntroduction à la POO en GoLes Structs comme ClassesDéfinir des méthodes sur les StructsReceveurs par pointeur vs par valeurInitialisation de StructsFonctions constructeursRécapitulatif - Calculatrice simple4Interfaces
Introduction aux interfacesImplémentation impliciteL'interface comme contratInterface vide (any)Assertion de typeType SwitchComposition d'interfacesInterfaces Stringer & ErrorRécapitulatif - Calculateur de formes7Encapsulation
Champs exportés vs non exportésEncapsulation au niveau du packageMéthodes Getter & SetterMasquage d'informations en GoRécapitulatif - Dossiers étudiants10Génériques (Go 1.18+)
Introduction aux génériquesParamètres de typeContraintes de typeStructures génériquesContournement pour les méthodes génériquesRécapitulatif - Collections génériques13Patrons de conception, Partie 1
Introduction aux Design PatternsPatron SingletonPatron FactoryPatron Abstract FactoryPatron ObserverPatron Strategy2Exploration approfondie des Types et Structs
Types de base et compositesDéfinitions de types personnalisésTags de StructStructs anonymesStructs imbriquéesValeurs par défaut et Zero ValuesRécapitulatif - Carnet de contacts5Composition plutôt qu'héritage
Pourquoi Go n'a pas d'héritageLes bases de l'imbrication de structsPromotion de méthodesImbriquer plusieurs structsImbrication vs AgrégationMasquage de méthodes imbriquéesRécapitulatif - Hiérarchie des employés8Gestion des erreurs & POO
L'interface errorTypes d'erreurs personnalisésError Wrapping (fmt.Errorf)Erreurs sentinelleserrors.Is() et errors.As()Panic, Defer et RecoverRécapitulatif - File Parser11Bibliothèque standard et POO
io.Reader & io.WriterL'interface sort.InterfaceL'interface fmt.Stringerencoding/json avec les StructsL'interface http.HandlerRécapitulatif - Modèles d'API REST14Patrons de conception, Partie 2
Patron CommandePatron AdaptateurPatron DécorateurPatron Template MethodPatron ÉtatPatron CompositeMiddleware en tant que Décorateur3Pointeurs et Mémoire
Bases des pointeurs en GoPointeurs vers des structsPassage par valeur vs référenceLa fonction new()Garbage Collection en GoRécapitulatif - Constructeur de liste chaînée6Le polymorphisme en Go
Le polymorphisme via les interfacesLe Duck Typing en GoRègles de satisfaction des interfacesCollections polymorphesInjection de dépendancesRécapitulatif - Processeur de paiement9Concurrence et POO
Bases des GoroutinesChannels et CommunicationChannels avec buffer vs sans bufferL'instruction Selectsync.Mutex et sync.RWMutexsync.WaitGroupConception de structures Thread-SafeRécapitulatif - Worker Pool