En savoir plus sur le garbage collector en Java

Bonjour! Lors de la dernière conférence, nous nous sommes familiarisés pour la première fois avec le mécanisme intégré du langage Java - le garbage collector. Il fonctionne en arrière-plan pendant l'exécution de votre programme, collectant les objets devenus inutiles, qui seront ensuite supprimés. De cette façon, cela libère de la mémoire pour créer de nouveaux objets dans le futur. Dans cette conférence, nous examinerons de plus près le principe de son fonctionnement. Par exemple, comment et à quel moment un objet devient-il inutile ? Et comment le ramasse-miettes est-il au courant de cela ? Nous répondrons à ces questions :) Notre cours est plutôt un aperçu : ce matériel n'a pas besoin d'être mémorisé. Il est destiné à élargir vos horizons concernant le travail de mémoire et le garbage collector, il suffira donc de le lire et d'apprendre quelque chose de nouveau par vous-même :) C'est parti ! La première chose dont vous devez vous rappeler est que le ramasse-miettes s'exécute en parallèle avec votre programme . Il n’en fait pas partie et fonctionne séparément : pour décrire cela, nous avons fait dans la dernière leçon une analogie avec un robot aspirateur. En fait, cela n’a pas toujours été le cas. Auparavant, le garbage collector était conçu de telle manière qu'il fonctionnait dans le même thread que votre programme. Et selon un certain calendrier, toutes les quelques minutes, il a commencé à vérifier la présence d'objets inutiles dans le programme. Le problème était que lors de cette vérification et de ce garbage collection, le programme se figeait et ne s'exécutait pas. Imaginez que vous êtes assis dans un bureau et que vous travaillez. Mais ensuite une femme de ménage arrive et doit laver les sols de la pièce. Elle vous expulse de derrière l'ordinateur pendant 5 minutes et vous attendez qu'elle ait fini de nettoyer. Pendant cette période, vous ne pouvez pas travailler. C'est à peu près ainsi que fonctionnaient les garbage collector :) Plus tard, ce mécanisme a été modifié, et désormais le garbage collector fonctionne en arrière-plan, sans ralentir le travail du programme lui-même. Vous savez déjà qu'un objet meurt lorsqu'il n'y a plus de références à lui. Mais le garbage collector ne compte pas réellement les références à . Premièrement, cela peut être assez long. Deuxièmement, ce n’est pas très efficace. Après tout, les objets peuvent faire référence les uns aux autres ! La figure montre un exemple dans lequel 3 objets se référencent les uns les autres, mais personne d'autre ne les référence. Autrement dit, ils ne sont pas nécessaires au fonctionnement du reste du programme. Si le garbage collector comptait simplement les références, tous ces 3 objets resteraient et ne libéreraient pas de mémoire : il y a des références vers eux ! Cela peut être comparé à un vaisseau spatial. Pendant le vol, les astronautes ont décidé de vérifier la liste des pièces de rechange à réparer et ont trouvé parmi elles un volant et des pédales provenant d'une voiture ordinaire. Ils ne sont clairement pas nécessaires ici et prennent de la place supplémentaire. Bien que ces pièces soient connectées et aient certaines fonctions, dans le cadre du fonctionnement du vaisseau spatial, elles constituent des déchets inutiles, dont il vaut mieux se débarrasser. Par conséquent, Java a décidé de créer la base du garbage collection sans compter les références, mais en divisant les objets en deux types - accessibles et inaccessibles.. Comment déterminer si un objet est accessible ? Tout ce qui est ingénieux est simple. Un objet est accessible s'il est référencé par un autre objet accessible. Il en résulte une « chaîne d’accessibilité ». Il démarre au démarrage du programme et se poursuit pendant toute la durée de son fonctionnement. Cela ressemble à ceci : La flèche dans la figure indique le code d'exécution de notre programme. Dans le code, par exemple dans la méthode main(), des références aux objets sont créées. Ces objets peuvent faire référence à de nouveaux objets, ceux-là à d'autres, et ainsi de suite. Une chaîne de liens d'objets est formée . Si un objet peut être atteint via cette chaîne de liens vers un « lien racine », c'est-à-dire directement créé dans le code en cours d'exécution, il est considéré comme accessible. Sur notre photo, ils sont indiqués en bleu. Mais si un objet est sorti de cette chaîne, c'est-à-dire qu'aucune des variables du code en cours d'exécution ne contient de références à celui-ci, et il est également impossible de l'atteindre via la "chaîne de liens" - il est considéré comme inaccessible. Dans notre programme, deux de ces objets sont indiqués en rouge. Attention : ces objets « rouges » ont des liens entre eux. Mais, comme nous l’avons dit plus tôt, le ramasse-miettes moderne en Java ne compte pas les références. Il détermine si un objet est accessible ou inaccessible . Par conséquent, les deux objets rouges sur la photo deviendront sa proie. Examinons maintenant l'ensemble du processus du début à la fin, et en même temps comment fonctionne la mémoire en Java :) Tous les objets en Java sont stockés dans une zone mémoire spéciale appelée tas . Dans le langage courant, un « tas » est une montagne d’objets où tout traîne en désordre. Mais le tas en Java n’est pas comme ça. Il a une structure très logique et raisonnable. Un beau jour, les programmeurs Java ont découvert que tous les objets de leurs programmes pouvaient être divisés en deux types : relativement parlant, les objets simples et les objets « à longue durée de vie » . Les objets « de longue durée » sont ceux qui ont survécu à de nombreuses collectes de déchets. Le plus souvent, ils existeront jusqu'à la fin du programme. En conséquence, le tas commun, où sont stockés tous les objets créés, a été divisé en plusieurs parties. La première partie a un beau nom - Eden (biblique « Jardin d'Eden »). C’est un bon nom car c’est là que vont les objets après leur création. C'est dans cette partie que la mémoire est allouée aux nouveaux objets lorsque nous écrivonsnew. De nombreux objets peuvent être créés, et lorsque l'espace vient à manquer dans cette zone, le premier garbage collection « rapide » commence. Il faut dire que le garbage collector est très intelligent et choisit un algorithme de travail en fonction de ce qu'il y a de plus dans le tas - des déchets ou des objets de travail. Si presque tous les objets sont des déchets, le collecteur marque les objets « vivants » et les déplace vers une autre zone mémoire, après quoi la zone actuelle est complètement nettoyée. S'il y a peu de déchets et que la plupart sont occupés par des objets vivants, il marque les déchets, les nettoie et range les objets restants. Nous avons dit « le collectionneur marque les objets « vivants » et les déplace vers un autre emplacement mémoire », mais lequel ? La zone mémoire où sont transférés tous les objets qui survivent à au moins un garbage collection est appelée Survival Space . Survival Space, à son tour, est divisé en générations . Chaque objet se voit attribuer une génération en fonction du nombre de garbage collection qu'il a subi. S’il y en a une, elle appartient à la « Génération 1 », si 5 – à la « Génération 5 ». Ensemble, Eden et Survival Space forment un espace appelé Young Generation . En plus de Young Generation, il existe une autre zone de mémoire dans le tas - Old Generation (« ancienne génération »). Ce sont des objets à très longue durée de vie qui ont survécu à de nombreuses collectes de déchets. Il est plus rentable de les stocker séparément de tous les autres. Et seulement lorsque la zone Ancienne Génération est pleine, c'est-à-dire Même s'il y a tellement d'objets à longue durée de vie dans le programme qu'il n'y a pas assez de mémoire, un garbage collection complet est effectué. Il ne traite pas une seule zone mémoire, mais généralement tous les objets créés par la machine Java. Naturellement, cela prend beaucoup plus de temps et de ressources. C'est pourquoi il a été décidé de stocker séparément les objets à longue durée de vie. Lorsque l’espace vient à manquer dans d’autres zones, ce que l’on appelle un « ramassage rapide des déchets » est effectué. Il ne couvre qu’un seul domaine et est donc plus économique et plus rapide. À la fin, alors que même la zone réservée aux centenaires est déjà saturée, le nettoyage complet entre en jeu. Ainsi, l’outil le plus « lourd » n’est utilisé par l’assembleur que lorsqu’il n’est plus nécessaire. Schématiquement, la structure du tas et du nettoyage ressemble à ceci :