Goroutines bloquées pour toujours : le ramasse-miettes de Go 1.27 les repère

19 octobre 2026 par Benoit

Ou : Comment le ramasse-miettes s’est mis à compter les gens qui attendent un appel que plus personne ne peut passer

Une fuite de goroutines ne fait aucun bruit. Pas de panique, pas d’erreur dans les journaux : une goroutine attend une valeur sur un canal que plus personne ne lira, et elle attendra jusqu’au prochain redémarrage, avec sa pile et tout ce qu’elle référence. Multiplie par le nombre de requêtes abandonnées dans la journée, et la mémoire du service grimpe sans raison apparente. Le profil goroutine classique montrait déjà ces goroutines, mais noyées parmi celles qui attendent légitimement, sans dire laquelle ne se réveillerait jamais. Go 1.27, sorti le 19 août 2026, rend disponible pour tous un profil qui fait précisément ce tri, goroutineleak¹. Il s’appuie sur le ramasse-miettes, ne se trompe pas quand il accuse, et se tait plus souvent qu’on ne le voudrait.

L’article sur les méthodes génériques de Go 1.27 promettait un article à ce profil. Le voici, avec du code exécuté sous Go 1.27.1 et des sorties copiées telles quelles.

Profil goroutineleak : détecter une fuite de goroutines en Go 1.27

La fuite la plus banale du monde

Voici le genre de fonction qu’on écrit un mardi après-midi : appeler un service lent, mais abandonner si le contexte expire avant la réponse.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Fetch abandonne si le contexte expire avant la réponse.
func Fetch(ctx context.Context, id int) (string, error) {
	ch := make(chan string) // non bufferisé : l'envoi attend un lecteur
	go func() {
		ch <- slowCall(id) // personne ne lira si Fetch est déjà parti
	}()
	select {
	case r := <-ch:
		return r, nil
	case <-ctx.Done():
		return "", ctx.Err()
	}
}

Tout est correct, sauf une chose. Le canal n’a pas de tampon : un envoi attend qu’un lecteur se présente. Quand le délai expire, Fetch repart par la branche ctx.Done(), et le seul lecteur possible s’en va avec elle. La goroutine anonyme termine son appel lent, tente de livrer son résultat, et reste plantée sur cette ligne pour l’éternité. Les notes de Go 1.26 prenaient déjà une fuite de cette famille en exemple, avec un retour anticipé dans une boucle².

Le standard téléphonique

Imagine un immeuble de bureaux où chaque employé bloqué attend un appel sur sa propre ligne. Pour savoir qui attend en vain, inutile d’interroger les employés : on demande au standard qui, parmi les gens encore actifs, a noté leur numéro. Si personne ne l’a, l’appel ne viendra jamais. Et si celui qui a le numéro attend lui-même un appel, il faut d’abord savoir si lui sera rappelé.

C’est l’algorithme, presque mot pour mot. Le ramasse-miettes part des seules goroutines exécutables, suit les pointeurs, et considère comme « finalement exécutable » toute goroutine bloquée sur un canal ou un verrou qu’il a pu atteindre. Il recommence jusqu’à ce que plus rien ne bouge. Les goroutines restantes attendent une primitive que personne ne peut plus toucher : elles sont déclarées fuyantes. Les notes de version le formulent ainsi : si la primitive P « is unreachable from any runnable goroutine or any goroutine that those could unblock », alors la goroutine « can never wake up »¹.

L’idée vient de Vlad Saioc et de trois coauteurs, dont Milind Chabbi, d’Uber, qui l’ont publiée à la conférence ASPLOS en 2025. Proposée à l’équipe de Go en juillet 2025, elle a tourné comme expérience dans Go 1.26 derrière GOEXPERIMENT=goroutineleakprofile, avant d’être activée par défaut dans Go 1.27². Elle ne coûte rien tant qu’on ne demande pas le profil : c’est la demande elle-même qui déclenche un cycle spécial du ramasse-miettes.

Ce que le profil affiche

Trois appels avec un délai de 10 millisecondes, face à un service qui en met 50, puis on demande le profil :

1
2
3
4
5

leak := pprof.Lookup("goroutineleak")
fmt.Println("Count avant :", leak.Count())
leak.WriteTo(io.Discard, 0) // déclenche le cycle de détection
fmt.Println("Count après :", leak.Count())
leak.WriteTo(os.Stdout, 1)

1
2
3
4
5
6
7
8

appel 0 : context deadline exceeded
appel 1 : context deadline exceeded
appel 2 : context deadline exceeded
Count avant : 0
Count après : 3
goroutineleak profile: total 3
3 @ 0x47f80a 0x41485c 0x414457 0x4e3ce9 0x485721
#	0x4e3ce8	example.com/fuites.Fetch.func1+0x48	example.com/fuites/fetch.go:18

Trois fuites, une seule pile, et la ligne exacte de l’envoi. Avec debug=2, le profil affiche toutes les goroutines au format d’une panique, et les fuyantes portent une mention explicite : goroutine 7 [chan send (leaked)]. Le même profil est servi par net/http/pprof à l’adresse /debug/pprof/goroutineleak, que j’ai interrogée sur un serveur de test. À garder derrière un port interne, comme tout le reste de /debug/pprof.

Regarde les deux lignes Count. La méthode ne lance pas la détection, elle rend le résultat du dernier cycle. Si tu exportes ce nombre vers ta supervision, appelle WriteTo d’abord, sinon ton tableau de bord affichera zéro avec une sérénité parfaite. Pas besoin de le faire souvent : une fuite ne se répare pas toute seule, elle sera encore là au passage suivant. Le billet de l’équipe de Go cite une collecte toutes les quatre heures comme exemple de fréquence en production³.

Ce qu’il ne verra jamais

Le profil ne se trompe pas quand il accuse, parce qu’il se tait dès qu’il a un doute. Pour mesurer ce silence, j’ai écrit un programme avec une goroutine bloquée par cas, puis demandé le profil :

Les deux premières absences sont documentées : une primitive accessible depuis une variable globale ou depuis une goroutine exécutable passe sous le radar¹. La troisième aussi : le billet du 2 septembre 2026 exclut les goroutines bloquées « for any other reason, e.g., file and network IO, or direct system calls »³. Une goroutine qui attend la réponse d’un serveur muet, sans délai, fuit autant que la mienne, et le profil ne la verra pas. Comme le détecteur de courses de go test -race, il ne trouve d’ailleurs que ce qui s’est déjà produit pendant l’exécution.

La dernière ligne m’a surpris, et je n’en ai trouvé aucune mention dans la documentation. Un sync.Mutex déclaré seul dans une fonction, verrouillé puis abandonné, n’a jamais été signalé dans mes essais. Le même verrou, rangé dans une structure avec une map, l’est dès la première demande. L’explication la plus probable se lit dans le code du runtime : les objets de moins de 16 octets sans pointeur partagent un bloc commun, qui reste vivant tant qu’un seul de ses occupants l’est, et les blocs en cours de remplissage sont marqués d’office à chaque cycle⁴. Un verrou de 8 octets hérite donc de la vie de ses voisins. Dans du vrai code, un verrou vit presque toujours dans une structure, mais la leçon dépasse ce cas : un profil vide ne prouve pas l’absence de fuite.

Dans les tests, deux outils plus sévères

Pour les tests, deux outils existaient déjà, et ils sont plus stricts que le profil. goleak, la bibliothèque d’Uber, liste à la fin d’un test toutes les goroutines qui ne se sont pas terminées⁵ :

1
2
3
4
5
6
7
8
9

=== RUN   TestLeakWithGoleak
    demo_test.go:17: found unexpected goroutines:
        [Goroutine 20 in state chan send, with example.com/fuites.Fetch.func1 on top of the stack:
        example.com/fuites.Fetch.func1()
        	example.com/fuites/fetch.go:18 +0x49
        created by example.com/fuites.Fetch in goroutine 19
        	example.com/fuites/fetch.go:17 +0x8f
        ]
--- FAIL: TestLeakWithGoleak (0.45s)

testing/synctest, stable depuis Go 1.25, exécute le test dans une bulle à horloge simulée et panique si une goroutine de la bulle reste bloquée à la fin : deadlock: main bubble goroutine has exited but blocked goroutines remain, suivi de la pile de la goroutine fautive, en état chan send (durable). Un piège au passage : l’horloge simulée s’arrête quand la fonction de test se termine. Même la version corrigée échoue si tu ne laisses pas passer le temps avant de sortir, avec un time.Sleep qui, dans la bulle, est instantané.

La différence avec le profil tient en un mot : le soupçon. goleak et synctest signalent toute goroutine encore vivante, perdue ou simplement en retard. Ils peuvent se le permettre, car ils travaillent dans un environnement que tu contrôles. Le profil ne signale que les cas prouvés, ce qui lui permet de tourner en production sans réveiller l’astreinte pour rien. L’équipe de Go conseille de combiner les trois³.

La correction, elle, tient en un caractère :

1

ch := make(chan string, 1) // une place : l'envoi ne bloque jamais

Avec une place dans le tampon, la goroutine dépose son résultat et se termine, que quelqu’un le lise ou non, et le ramasse-miettes récupère ensuite le canal. Dans mon dépôt de test, le profil compte bien trois fuites sur l’ancienne version, et goleak comme synctest acceptent la nouvelle.

DevOps Dave : J’ai branché /debug/pprof/goroutineleak sur la supervision. Zéro fuite depuis un mois.

Security Sarah : Et le nombre total de goroutines ?

DevOps Dave : Il monte un peu chaque jour. Mais le profil dit zéro.

Security Sarah : Le profil dit qu’il n’a rien pu prouver. Tes goroutines attendent peut-être un serveur qui ne répondra jamais.

Tout le code de cet article a tourné sous Go 1.27.1 sur Linux, avec go vet, le détecteur de courses et goleak 1.3.0 ; les chemins des sorties sont raccourcis par -trimpath. Le standard téléphonique de Go 1.27 sait désormais dire qui attend un appel que plus personne ne peut passer. Il ne sait pas dire qui attend un appel que quelqu’un pourrait passer, mais ne passera jamais. Pour ceux-là, il reste un délai sur chaque appel réseau, et un test qui échoue avant la mise en production.

À lire aussi