Quand et comment un chargeur de classe Java est-il sélectionné pour la récupération de place?

Question

Nous sommes de la création de plusieurs enfants chargeurs de classes à charger dans plusieurs subapplications dans une application Java "conteneur", le prototypage de déploiement à chaud. Lorsque le chemin de classe d'un chargeur de classe a changé (c'est à dire les pots ont été ajoutés, supprimés, mis à jour), l'ancien chargeur de classe est jeté (non référencés) et un nouveau chargeur de classe est créée pour la nouvelle classpath des jarres.

Après la mise à jour du classpath, le déclenchement du déploiement à chaud, nous avons pris un tas de vidage. Le tas de vidage (à l'aide de la Mémoire de l'Analyseur) indique que les vieux chargeurs de classes n'étaient pas des ordures collectées. Certaines classes dans le chargeur de classe parent ont été la mise en cache du vieux chargeurs de classes. Les choses suivantes ont été invoquées pour effacer ces caches:

java.lang.ResourceBundle.clearCache(classLoader);
org.apache.commons.logging.LogFactory.release(classLoader);
java.beans.Introspector.flushCaches();

Même après effacement de la ci-dessus les caches, l'ancien chargeur de classe sont toujours pas nettoyée. Le reste des références pour le chargeur de classe comprenait les éléments suivants:

• les classes chargées par le chargeur de classe
• java.lang.Package créé par le chargeur de classe elle-même
• java.lang.ProtectionDomain créé par le chargeur de classe elle-même

Tous les ci-dessus sont des références circulaires dans le chargeur de classe, ce qui devrait inciter à la collecte des ordures. Je ne suis pas sûr de savoir pourquoi il ne l'est pas. Quelqu'un sait pourquoi les vieux chargeurs de classes ne sont pas encore des ordures collectées, même avec les références circulaires?

Answer 1

J'ai toujours entendu dire que l' Classloader le déchargement est problématique. Ils sont théoriquement des ordures collectées quand il n'y a pas de référence pour les instances d'objet et de classe le déchargement n'est pas nécessaire, mais dans la pratique, il semble être plus problématique. De subtiles références peuvent fuir et éviter l' Classloader d'être remis en état. Dans les serveurs d'application, après de nombreuses redéployer cycle, j'ai parfois eu un OutOfMemoryError: PermGen space.

Tout ça pour dire que je pense qu'il y a un méchant de référence quelque part qui l'empêche d'être collectées, peut-être que la mémoire de l'analyseur n'a pas suivi le lien correctement. Il semble que tout ce qui peut arriver, comme décrit dans les articles suivants:

• Chargeur de classe de fuites: le redouté PermGen space exception
• Comment fixer le redoutable PermGen space exception

Aussi, je ne sais pas exactement ce que vous faites, mais si vous pouvez attendre pour JDK 7, vous pourriez avoir un coup d'oeil à l' AnonymousClassLoader. Elles seront introduites afin de mieux soutenir les dynamiques de la langue, comme expliqué dans ce post:

• Un avant-goût de InvokeDynamic

J'espère que ça va vous aider.