Les objets sont créés à l'aide de nouveaux, mais il n'y a pas de fonctionnement correspondant pour recycler la mémoire occupée par l'objet. Lorsque nous terminons l'utilisation d'un objet, nous cessons simplement de se référer à cet objet: modifiez notre référence en point vers un autre objet ou à Null; ou revenez de la méthode afin que les variables locales de la méthode n'existent plus, de sorte que la référence à ces variables locales ne pointera à aucun objet. Les objets qui ne sont plus référencés sont appelés ordures. Le processus de recherche et de recyclage de ces objets s'appelle la collecte des ordures o
Les machines virtuelles Java utilisent la collection de déchets pour s'assurer que les objets référencés seront conservés en mémoire et libéreront également l'espace de stockage occupé par des objets inaccessibles via toute référence dans le code d'exécution. Ceci est une garantie forte que si un objet n'est pas recyclé si la chaîne de référence à partir de la référence racine (c'est-à-dire des références qui peuvent être directement accessibles dans le code d'exécution).
En bref, lorsque nous ne pouvons pas atteindre un objet à partir d'un code exécutable, l'espace nécessaire peut être recyclé. Notez que nous utilisons le mot «peut» car si l'espace mémoire est recyclé est déterminé par le collecteur des ordures. Généralement, le collecteur des ordures ne fonctionnera que si plus d'espace mémoire est nécessaire ou pour éviter un débordement de mémoire. Cependant, le programme peut sortir sans débordement de mémoire, ou même lorsqu'il n'est pas proche de la mémoire, il peut donc ne pas nécessiter de collecte de déchets. Dans toutes les méthodes actuellement exécutées, si toutes les variables contiennent des références à un objet, et à partir de ces variables, les références à cet objet ne peuvent pas être trouvées dans tous les domaines ou éléments du tableau le long de la chaîne de référence, alors nous disons que l'objet est "inaccessible".
Le recyclage des ordures signifie que nous n'avons jamais à nous soucier des références qui pendaient. Dans les systèmes où les programmeurs peuvent contrôler directement lorsque les objets sont supprimés, les programmeurs peuvent supprimer des objets auxquels d'autres objets font toujours référence. Si les programmeurs suppriment ces objets, les références qui font toujours référence aux objets supprimées deviendront vides car ils se réfèrent au silence.
Le système le considère comme un espace mémoire allocable (mais en fait, l'espace a été libéré). Le système peut allouer cet espace allocable à de nouveaux objets, de sorte que les références à l'origine pointées vers l'espace entraînent réellement des objets complètement différents de ce à quoi ils s'attendaient. Dans ce cas, des catastrophes imprévisibles peuvent se produire lorsque le programme utilise des valeurs stockées dans cet espace et les exploite comme des objets auxquels ils n'appartiennent pas. La collecte des ordures résout le problème de suspendre les références pour nous, car tous les objets qui sont encore référencés ne seront pas traités comme une collection de déchets, de sorte que l'espace qu'ils occupent ne peuvent pas être libérés. La collecte des ordures résout également le problème de la suppression accidentelle du même objet plusieurs fois - ce problème peut également provoquer des catastrophes. Le recyclage des objets à ordures ne nécessite pas notre intervention, mais le recyclage des ordures occupera une certaine quantité de ressources système. La création et le recyclage d'un grand nombre d'objets peuvent interférer avec des applications critiques, donc lors de la conception de ces systèmes, nous devons soigneusement gérer le nombre d'objets créés afin de réduire la quantité de déchets à recycler.
La collecte des ordures ne garantit pas que la mémoire aura toujours de l'espace pour créer de nouveaux objets. Par exemple, si nous continuons à créer des objets et à les mettre dans une liste, nous ne pouvons plus créer de nouveaux objets lorsqu'il n'y a pas assez d'espace pour créer de nouveaux objets et qu'il n'y a pas d'objets non référencés. Si nous conservons les références de liste ci-dessus aux objets qui ne sont plus nécessaires, une fuite de mémoire se produira. La collection d'ordures résout de nombreux problèmes d'allocation de mémoire (mais pas tous).
Interagir avec le collecteur des ordures
Bien que le langage Java lui-même n'ait pas de moyen explicite de éliminer les objets inactifs, nous pouvons toujours trouver des objets qui ne sont plus utilisés en appelant directement le collecteur des ordures. Certaines méthodes pratiques de la classe d'exécution et de la classe système nous permettent d'appeler le collecteur des ordures, de demander l'exécution de tous les finalisateurs ou d'afficher l'état de mémoire actuel:
.Public void gc Q: Cette méthode demande à la machine virtuelle Java de dépenser des objets de recyclage d'énergie qui ne sont plus utilisés afin qu'il puisse réutiliser la mémoire occupée par ces objets.
.Public void runfinalisation (): Cette méthode demande à la machine virtuelle Java de dépenser de l'énergie à diriger les finalisateurs suivants: objets qui ont été jugés inaccessibles mais dont le finalisateur n'a pas encore été exécuté.
"Public Long Freedom (): Renvoie le nombre estimé d'octets disponibles dans la mémoire du système.
・ Public Long Total Memory (): Renvoie le nombre total d'octets dans la mémoire du système.
.Public long MaxMemoryo: Renvoie le nombre maximal d'octets de mémoire système disponible pour la machine virtuelle Java. Si le système d'exploitation n'a pas de restrictions d'utilisation de la mémoire sur les machines virtuelles Java, longs. La valeur maximale sera retournée. Il n'y a pas de méthode en Java pour définir la mémoire maximale du système. Habituellement, les machines virtuelles Java définissent cette valeur via la ligne de commande ou d'autres options de configuration.
Pour appeler la méthode ci-dessus, nous devons obtenir une référence à l'objet d'exécution actuel via la méthode statique runtime.getRuntime. La classe système prend en charge les méthodes statiques GC et Runfinalisation, qui appellent les méthodes correspondantes sur l'objet RunT-IME actuel; En d'autres termes, System.gc () est équivalent à Runtime.getRuntime (). GC () Méthodes.
Lorsque vous appelez la méthode runtime.gc (), le collecteur des ordures peut ne pas libérer de mémoire supplémentaire, car il peut ne pas y avoir de ordures pour être recyclées, et tous les collectionneurs de déchets ne peuvent pas découvrir des objets recyclables à la demande. Par conséquent, appeler le collecteur des ordures peut n'avoir aucun effet. Cependant, appeler la méthode runtime.gc () est souhaitable avant de créer un grand nombre d'objets, en particulier dans les applications critiques dans le temps où les frais généraux de collecte des ordures peuvent l'affecter. Il y a deux avantages potentiels à l'exécuter: le premier est que nous pouvons obtenir autant de mémoire que possible avant d'exécuter l'application, et la seconde est que nous pouvons réduire la possibilité que le collecteur des ordures fonctionne pendant l'exécution des tâches. La méthode suivante libère activement tout l'espace qui peut être publié au moment de l'exécution:
public static vo enregistreful1gc () {runtime rt = runtime.getRuntime (); long isfree = rt.freememory (); longtemps sans être fidèle; do {wasfree = isfree; rt.runfinalisation (); rt.gc (); isfree deux rt.freememory (); } while (isfree> wasfree); }La méthode est constamment en boucle, et la valeur de FreeMemory continue d'augmenter en appelant en continu les méthodes Runfinalisation et GC. Lorsque la quantité de mémoire libre n'augmente plus, la boucle de la méthode se termine.
Nous n'avons généralement pas besoin d'appeler la méthode Runfinalisation car la méthode finalisée est appelée asynchrone par le collecteur de déchets. Dans certains cas, par exemple, lorsqu'une ressource qui peut être recyclée par la méthode Finalise est épuisée, il sera utile d'appliquer autant de terminaisons que possible en appelant la finalisation de l'exécution. Mais n'oubliez pas que nous ne pouvons garantir qu'un objet en attente de résiliation utilise cette ressource, donc Runfinalisation peut n'aura aucun effet.
La méthode FullGC semble trop radicale pour la plupart des applications. Dans des cas spéciaux où la collecte des ordures est requise, même si toutes les ordures disponibles ne sont pas collectées par un seul appel à la méthode System.GC, c'est la grande majorité. Par conséquent, les appels répétés réduiront le taux de sortie de la collecte des ordures, et dans de nombreux systèmes, ces appels répétés sont sans découverte.