L'utilisation d'un trop grand nombre de variables statiques peut-elle provoquer une fuite de mémoire en Java?

Question

Si mon application a trop de variables ou de méthodes statiques, elles seront stockées dans la pile conformément à la définition. S'il vous plait corrigez moi si je me trompe

1) Ces variables seront-elles sur le tas jusqu'à la fermeture de l'application?
2) Seront-ils disponibles pour le GC à tout moment? Si non, puis-je dire que c'est une fuite de mémoire?

Answer 1

Les méthodes statiques sont juste des méthodes, elles ne sont pas stockées sur le tas, ils n'ont tout simplement pas l'habitude d'utiliser un "ce" paramètre.

Les variables statiques servent de "racines" de la GC. En conséquence, sauf si vous explicitement définie sur null, ils vivront aussi longtemps que le programme de vie, et donc, tout est accessible à partir d'eux.

Une situation est considérée que comme une fuite de mémoire si vous avez l'intention pour que la mémoire de devenir libre et il ne deviendra pas gratuit. Si vous avez l'intention de votre variable statique pour contenir une référence à un objet, une partie du temps, et que vous oubliez de le mettre à null lorsque vous avez terminé avec cet objet, vous auriez probablement jusqu'à la fin avec une fuite. Toutefois, si vous le mettez dans une variable statique et l'intention qu'il sera là tant que le programme est en cours d'exécution, alors il n'est certainement pas une fuite, il est plus probable d'un "permanent singleton". Si l'objet reçu récupérée alors que vous vouliez qu'il existe encore, qui aurait été très mauvais.

Quant à votre question sur le tas: Tous les objets en Java exister, soit sur le tas ou sur la pile. Les objets sont créés sur le tas avec l'opérateur new. Une référence est ensuite attaché à eux. Si la référence est ou devient nulle ou est hors de portée (par exemple, la fin du bloc), le GC se rend compte qu'il n'y a aucun moyen d'atteindre l'objet et la reprend-il. Si votre référence est dans une variable statique, il ne tombe jamais hors de portée, mais vous pouvez toujours mettre à null ou à un autre objet.

Answer 2

Si vous avez un hashmap statique et que vous y ajoutez des données ... les données ne disparaîtront jamais et vous aurez une fuite - au cas où vous n'en auriez plus besoin. Si vous avez besoin de données, il ne s'agit pas d'une fuite, mais d'une énorme pile de mémoire.

Answer 3

Les objets directement ou indirectement référencés par la statique resteront sur le tas jusqu'à ce que le chargeur de classe approprié puisse être collecté. Il existe des cas (ThreadLocal, par exemple) où d'autres objets référencent indirectement le chargeur de classes, le rendant ainsi non collecté.

Si vous avez une liste statique, par exemple, et ajoutez des références à celle-ci de manière dynamique, vous pouvez très facilement vous retrouver avec des "problèmes de conflit de durée de vie d'objet". Évitez les statiques mutables pour plusieurs raisons.

Answer 4

Cela ne causera pas de fuite de mémoire au sens classique du C ... Par exemple

 Class A{

static B foo;

...

static void makeFoo(){
   foo = new B();
   foo = new B();
}
 

Dans ce cas, un appel à makeFoo () ne provoquera pas une fuite de mémoire, car la première instance peut être nettoyée.

Answer 5

Aussi longtemps que vous pouvez faire référence à ces variables à partir de quelque part dans le code, il ne peut pas par GCed ce qui signifie qu'ils seront là jusqu'à la fin de l'application.

Pouvez-vous appeler cela une fuite de mémoire, je n'appellerais pas ça une fuite de mémoire, généralement une fuite de mémoire est une mémoire qui vous normalement s'attendre à récupérer, mais vous n'avez jamais le faire, ou vous ne récupérer qu'une partie. Aussi des fuites de mémoire, généralement de s'aggraver dans le temps (par exemple: chaque fois que vous appelez une méthode plus la mémoire est "fuite") mais dans ce cas, l'utilisation de la mémoire pour les variables est (un peu) statique.