1. Comment fonctionne le garbage collector en Java
Le garbage collector est un processus de faible priorité qui s'exécute périodiquement et libère la mémoire utilisée par les objets qui ne sont plus nécessaires. Le garbage collector s'exécute en arrière-plan, en parallèle avec le programme, dans un thread séparé. La base du garbage collection n'est pas le comptage de références, mais la séparation des objets en deux types - accessibles et inaccessibles. Un objet est considéré comme accessible (vivant) s'il est référencé par un autre objet accessible (vivant). L'accessibilité est comptée à partir des threads. Les threads en cours d'exécution sont toujours considérés comme accessibles (vivants), même si personne ne les référence. Tous les objets en Java sont stockés dans une zone mémoire spéciale appelée tas. Tous les objets dans les programmes peuvent être divisés en deux types : relativement parlant, les objets simples et les objets « à vie longue ». 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"), les objets vont ici après leur création. C'est dans cette partie que la mémoire est allouée aux nouveaux objets lorsque nous en écrivons de nouveaux. 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. 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 qu’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, Lorsque même la zone réservée aux résidents de longue date est déjà saturée, un 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.
2. Quels types de éboueurs existe-t-il ?
Java dispose de sept types de garbage collector :
Collecteur de déchets en série
Collecteur de déchets parallèle
Récupérateur de déchets CMS
Collecteur de déchets G1
Epsilon Garbage Collector
Éboueur Z
Éboueur à Shenandoah
3. Que sont les « générations » d’objets
Tous les objets de Survival Space sont divisés 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 ».
4. À quoi sert SoftReference ?
Un objet référencé uniquement par des références logicielles peut être récupéré si le programme manque de mémoire. Si un programme manque soudainement de mémoire, avant de lancer une exception OutOfMemoryException, le garbage collector supprimera tous les objets référencés par des liens symboliques et tentera à nouveau d'allouer de la mémoire au programme. Un objet qui est empêché de mourir uniquement par SoftReference peut survivre à un certain nombre de garbage collection et sera très probablement détruit si le programme manque de mémoire.
5. Exemple d'utilisation de SoftReference
Les SoftReferences ont été spécialement conçues pour la mise en cache. Supposons qu'un programme client demande fréquemment diverses données à un programme serveur. Ensuite, le programme serveur peut mettre certains d'entre eux en cache, en utilisant SoftReference pour cela. Si les objets préservés de la mort par des références logicielles occupent la majeure partie de la mémoire, alors le ramasse-miettes les supprimera simplement et c'est tout.
6. Exemple d'utilisation de WeakReference
S’il n’y a que des références faibles à un objet, alors cet objet est vivant, mais il sera détruit lors du prochain garbage collection. Un objet qui est empêché de mourir par WeakReference seul ne survivra pas au prochain garbage collection. Mais en attendant, vous pouvez l'obtenir en appelant une méthode get()sur WeakReference et en appelant ses méthodes ou en faisant autre chose. Un exemple d'utilisation de WeakReference est WeakHashMap.
7. Pourquoi WeakHashMap est nécessaire
WeakHashMap est un HashMap dont les clés sont des références faibles - WeakReference. Vous stockez des paires d'objets dans un WeakHashMap - une clé et une valeur. Mais WeakHashMap ne fait pas référence aux clés directement, mais via WeakReference. Par conséquent, lorsque les objets utilisés comme clés deviennent inaccessibles, ils seront détruits lors du prochain garbage collection. Cela signifie que leurs valeurs seront automatiquement supprimées du WeakHashMap. WeakHashMap est très pratique pour stocker des informations supplémentaires sur certains objets. Premièrement, il est très facile à obtenir si vous utilisez l'objet lui-même comme clé. Deuxièmement, si un objet est détruit, celui-ci ainsi que toutes les données qui lui sont associées disparaîtront du HashMap. Par exemple, le programme dispose d'un thread qui surveille le travail de certains objets de tâche et écrit des informations les concernant dans le journal. Ensuite, ce fil peut stocker les objets suivis dans un tel WeakHashMap. Dès que les objets ne sont plus nécessaires, le garbage collector les supprimera et les références à eux depuis WeakHashMap seront automatiquement supprimées.
8. Qu'est-ce qu'un enregistreur
Un objet Logger est utilisé pour enregistrer les messages pour un système ou un composant d'application spécifique. Un journal est une liste d'événements survenus. Le plus souvent, des informations sur les paramètres de la méthode avec laquelle elle a été appelée, toutes les erreurs interceptées et de nombreuses informations intermédiaires sont écrites dans le journal. L'ensemble du processus de journalisation se compose de trois parties.
La première partie consiste à collecter des informations.
La deuxième partie consiste à filtrer les informations collectées.
La troisième partie est un enregistrement des informations sélectionnées.
9. Comment configurer un enregistreur
Ajoutez une dépendance à pom.xml.
Ajoutez le fichier log4j.properties aux ressources.
En règle générale, les paramètres de l'enregistreur log4j sont définis dans le fichier log4j.properties. Dans ce fichier, vous pouvez spécifier plusieurs appenders - objets dans lesquels les données seront écrites.
Ajoutez à la classe avec la logique métier private static final Logger log = Logger.getLogger(ххх.class);.
GO TO FULL VERSION