Fuite de mémoire, les pièges de l'API Standard de Java

Question

Quelles classes de la Norme Java API peut provoquer des fuites de mémoire lorsqu'ils sont utilisés (pas bien évidemment) la mauvaise voie? Et comment ces fuites de mémoire être évitée/fixe?

Exemple: ObjectInputStream et ObjectOutputStream garder les références à tous les objets qu'ils ont vu pour envoyer ultérieurement les occurences d'un même objet comme des références plutôt que des copies (et donc de traiter avec des références circulaires). Cela provoque une fuite de mémoire lorsque vous gardez un tel flux indéfiniment ouverts (par exemple, lorsque vous l'utilisez pour communiquer sur le réseau).

Correctif: Appel reset (), périodiquement ou après chaque objet de plus haut niveau.

Answer 1

Un gros est que l'obtention de sous-chaînes de cordes de Java se réfère à la chaîne d'origine.

Exemple: vous lisez dans un 3000 caractères enregistrer et d'obtenir une sous-chaîne de 12 caractères, de retour qu'à l'appelant (dans la même JVM). Même si vous n'avez pas directement référence à la chaîne d'origine, que 12 chaîne de caractères est toujours à l'aide de 3000 caractères dans la mémoire.

Pour les systèmes qui les reçoivent et ensuite d'analyser un grand nombre de messages, cela peut être un véritable problème.

Vous avez un couple de façons d'éviter cela:

String sub = new String(str.substring(6,12));

ou

String sub = str.substring(6,12).intern();

Le premier est plus clair. Le second a d'autres implications, parce que vous utilisez PermGen space. Galvaudé, vous pourriez exécuter, à moins que vous donnez à votre VM assez.

Rappelez-vous ce n'est pertinente que si vous prenez les petites chaînes, puis de le jeter au loin la chaîne d'origine et que vous êtes en train de faire beaucoup.

Answer 2

Tout ce que vous vous inscrivez en tant que destinataire d'un Événement, par exemple dans le GUI de cadres, ne peut pas être nettoyée tant qu'il est enregistré et la source de l'événement est vivant.

Cela peut introduire des fuites de mémoire, si un développeur n'est pas conscient de ce que référence forte à partir de la source de l'événement à l'événement de l'abonné.

Answer 3

Tout non-statique à l'intérieur des classes de vous faire tenir sur à l'extérieur des classes. De sorte que l'air innocent intérieur de la classe peut retenir un énorme objet graphique. Mettre l'instance en statique ou de l'application de la collecte de quelque part et vous êtes à l'aide d'une beaucoup de mémoire, vous n'êtes pas censé être en utilisant.

Answer 4

Chaque instanciation d'un Thread alloue de la mémoire pour une pile (par défaut 512k, accordables par -Xss). Ce n'est pas une fuite en tant que tel, mais un naïf tentative massivement multi-thread une demande donnera lieu à un nombre considérable de non-évidence la consommation de mémoire.

Answer 5

Toute la classe avec la méthode dispose ()?

Par exemple java.awt.La fenêtre n ° disposer:

public void disposer()

Les communiqués de tous les natifs de l'écran ressources utilisées par cette Fenêtre, ses sous-composants, et l'ensemble de ses propres enfants. Qui est, les ressources de ces Composants sera détruit, toute la mémoire qu'ils consomment sera retourné à l'OS, et ils seront marqués comme undisplayable.