Réclamation automatique de la mémoire inutilisée dans un environnement d’exécution de programmes en identifiant et en libérant les objets qui ne sont plus accessibles depuis les racines du programme ou nécessaires à son exécution.

Principe

La plupart des collecteurs se fondent sur l’analyse de l’accessibilité ou de la vivacité : les objets accessibles depuis les références racines (piles, registres, variables globales) sont considérés vivants ; les objets inaccessibles sont récupérables. Idées organisatrices courantes : traçage (mark‑and‑sweep, copie), comptage de références, hypothèse générationnelle, collecte incrémentale/parallelle pour équilibrer pauses et débit.

Démonstration

Exemples : un collecteur générationnel de la JVM qui promeut les objets durables entre jeunes et vieilles générations et effectue des minor collections stop‑the‑world ; le comptage de références de Python avec un détecteur de cycles auxiliaire ; des collecteurs concurrents qui s’exécutent parallèlement aux threads mutateurs pour réduire les pauses.

Mauvaise application

Supposer que la collecte automatique élimine toutes les erreurs liées à la mémoire — le GC ne peut pas récupérer des objets accessibles mais inutilisés (fuites de mémoire dues à des références persistantes), ni gérer automatiquement les ressources non mémoire (descripteurs de fichiers, sockets) sauf à utiliser prudemment des finaliseurs ou des motifs RAII. Considérer les pauses du GC comme négligeables dans des systèmes temps réel ou sensibles à la latence est une erreur fréquente.

Conséquence

Un GC correctement conçu réduit les erreurs de gestion manuelle de mémoire (use‑after‑free, double‑free) et allège la charge du programmeur, permettant des abstractions plus sûres. Il introduit un surcoût d’exécution, des pauses potentielles et un caractère nondéterministe de la reprise de la mémoire, à gérer dans les contextes sensibles à la latence.

Inversion

La gestion manuelle de la mémoire (allocation et désallocation explicites par le programmeur ou destructeurs déterministes) offre des points de récupération prédictibles et souvent un coût de fonctionnement plus faible mais augmente le risque de corruption mémoire, de fuites et d’erreurs de programmation.

Limite

S’applique aux environnements gérés et aux tas où le runtime contrôle la durée de vie des objets ; exclut le paging/swapping au niveau OS, le nettoyage de systèmes de fichiers et la récupération de ressources non mémoire sauf si le runtime les prend explicitement en charge. Les différentes stratégies de GC fournissent des garanties différentes (par ex. bornes de pause, débit) et tous les runtimes n’exposent pas la même sémantique.

Tension sémantique

Tension entre GC automatique et gestion déterministe des ressources (RAII/ownership), et entre systèmes à latence prévisible et architectures orientées débit ; les choix de GC arbitrent facilité de programmation contre latence, usage mémoire et coût CPU.

Synthèse

La collecte des ordures est le mécanisme runtime qui identifie et récupère automatiquement la mémoire non accessible selon l’ensemble racine et le modèle mémoire du programme ; il réunit traçage et comptage avec des stratégies générationnelles et concurrentes pour arbitrer pauses, débit et complexité tout en laissant au programmeur la gestion des ressources non mémoire et des fuites accessibles.