Si une variable d'objet est encore pointe vers un objet qui est d'aucune utilité, alors JVM ne sera pas garbage collecter cet objet et de l'objet reste en fuite de mémoire la création de la mémoireLe scénario suivant est-il appelé memory-leak dans java? Est-ce que ce n'est pas Garbage Collected?
Dans le scénario ci-dessus, il est possible de la fuite de mémoire .. Pourquoi est-ce pas Garbage Collected? Quelqu'un peut-il élaborer à ce sujet?
Un exemple typique est un écouteur d'événement. Chaque fois qu'un écouteur d'événement est enregistré, une référence à cette classe est conservée. Si l'objet est disposé mais l'écouteur d'événement non non enregistré, l'objet ne soit libéré de la mémoire en raison de la référence à l'écouteur d'événement.
Plus d'infos ici: http://www.javaworld.com/javaworld/javatips/jw-javatip79.html
Parce que si un objet qui est en cours d'utilisation a encore une référence à un autre objet que vous souhaitez recueillir, l'objet en cours d'utilisation peut utiliser encore et prendre des mesures sur l'objet que vous voulez récupérer. Si un objet ne sert à rien, la référence doit être supprimée afin que l'objet puisse être récupéré.
Collecte des ordures ménagères lui-même ne vous empêche pas de fuites de mémoire. Il existe des scénarios où il est très possible de fuir la mémoire. Vous venez de trouver l'un de ces nombreux scénarios.
Tant que quelqu'un a une référence à un objet, il peut être utilisé et la JVM ne peut pas le ramasser. La JVM détermine si les clusters d'objets sont toujours utilisés en recherchant un chemin de références de la racine vers les objets en question. Cela signifie qu'un groupe d'objets qui se référencent les uns les autres mais qui ne sont pas référencés à partir du reste du système obtiendront le garbage collecté.
donc simplement d'avoir un objet pointant vous ne vous empêchera pas d'être ramasse-miettes.
Un scénario typique où cela peut se produire est lorsque vous avez une carte statique, qui est remplie, mais jamais effacée. La carte ne peut pas être garbage collection, puisqu'elle est appelée statiquement, et les entrées de la carte ne peut pas être garbage collection, car ils sont appelés à partir de la carte.
Si vous avez une référence à l'objet, comment la JVM est-elle censée savoir qu'elle est "inutile"? Si vous n'en avez pas besoin, supprimez la référence et la JVM peut dire que vous n'avez plus l'intention de l'utiliser. Le GC en Java est assez bon, mais il ne peut pas lire dans vos pensées ou déterminer l'intention de vos codes.
Il n'est pas collecté car la JVM ne peut pas dire si la référence de cette variable d'objet sera suivie dans le futur. Une telle détermination exigerait, dans le cas général, que la JVM résolve le problème d'arrêt.
Idéalement, un gestionnaire de mémoire automatique libérerait des objets qui ne seront pas de toute utilisation ultérieure de l'application.
Il a été prouvé qu'il n'est pas possible de déterminer, avec une précision de 100% et dans toutes les situations, si un objet donné sera utilisé par la suite.À la place, les garbage collectors utilisent la «meilleure chose suivante»: ils libèrent des objets qui ne sont pas accessible: un objet auquel on ne peut accéder à partir de l'application, faute d'un chemin de références à cet objet, ne sera jamais utilisé à nouveau par l'application car il n'y a aucun moyen pour l'application de remarquer même que l'objet existe toujours. C'est une approximation mais c'est sûr: le GC ne libèrera pas un objet qui est encore utilisé, mais il pourrait ne pas libérer un objet qui ne sera plus utilisé, si cet objet semble être joignable (ie l'application peut encore atteindre et saisir l'objet, si elle le souhaite). Une "fuite de mémoire" est une situation dans laquelle les objets inutilisés utilisent une quantité excessive de mémoire vive (RAM). Ce qui est "démesuré" dépend de l'application. Un seul objet inutilisé est rarement un problème. Les fuites importantes habituelles sont des situations où des objets inutilisés mais atteignables s'accumulent par milliers.
Je suis généralement d'accord avec ce que vous avez écrit, sauf que je définirais une fuite de mémoire comme une situation dans laquelle la mémoire consommée par des objets sans signification sémantique peut devenir un multiple illimité de la mémoire consommée par des objets utiles. Un programme qui nécessite une mémoire illimitée pour effectuer une tâche qui ne nécessite que de la mémoire limitée peut ne pas avoir de fuite (par exemple trouver un nombre pair ou impair de lignes en lisant des morceaux dans une liste chaînée puis compter les nouvelles lignes une fois lues), mais les programmes avec des fuites nécessitent une mémoire illimitée. – supercat
Travail à domicile? (15chrlmt) – LiraNuna