Comment décharger la classe de Java
J'ai été invité à cette question plusieurs fois. Récemment Xyling a posé la même question dans son blog. Ainsi j'ai pensé qu'une explication simple peut être en règle.
Pour décharger une classe vous devez créer un classloader fait sur commande et charger la classe utilisant elle. Le Tomcat la fait et ainsi fait JRun. Vous pouvez regarder en code de Tomcat pour un exemple.
Après que vous soyez fait avec la classe vous devez libérer toutes les références à la classe aussi bien qu'au chargeur de classe en attribuant à nouveau les variables ou en les plaçant pour annuler.
Puis l'attente System.gc () pour décharger la classe ou vous l'appellent directement dans une boucle jusqu'à ce que plus de bytes ne puissent être libérés. l'appeler de quelque manière que normalement fait deux fois le tour.
Note : Vous ne pouvez pas décharger une classe simple. Vous devez décharger le classloader avec lui. Tellement évidemment le classloader de système n'est pas l'approprié à cette tâche.
Note 2 : C'est comment des pages de JSP vous sont rechargé dynamiquement chaque fois changement le code. Et oui c'est pourquoi la première fois prend beaucoup plus longtemps pour charger alors des périodes suivantes.
Classé sous comment à, logiciel de Java, technologie | 
|
RSS 2.0 | 
Envoyez cet article
Vous pouvez également aimer lire |
Ajoutez aux favoris de Technorati
15 mars 2005 à 6:31 P.M.
Bonjour,
Merci infiniment de cette information.
Occupez-vous de si je prolonge ma question ici elle-même ? En fait, je charge mes classes par URLClassLoader. Et Général je suis des dossiers de FIOLE de chargement par URLClassLoader. Maintenant je veux que ce dossier de FIOLE soit déchargé. Est-ce que je peux prolonger votre logique à URLClassLoader pour des dossiers de FIOLE aussi ?
15 mars 2005 à 6:33 P.M.
Merci.
15 mars 2005 à 6:41 P.M.
En fait, le temps de premier-charge de JSP est non seulement dû à la classe étant rechargée, (le chargement d'une classe du bytecode ne prend pas cela longtemps, s'il faisait Java serait beaucoup plus lent qu'il est ; -). Un nombre de heures plus significatif est dépensé produisant du bytecode, pendant qu'un changement à la source de JSP doit être converti d'abord en source de Java, et puis dedans le byte-code, qui peut alors être chargé par le ClassLoader. Ainsi, additionnez deux analysent/produisent des cycles à une charge de byte
16 mars 2005 à 4:28 P.M.
Si vous êtes intéressé à voir une torsion intéressante sur le rechargement dynamique des classes, vérifiez la source dans notre moteur embrochable chez http://www.platonos.org. Nous chargeons non seulement les connexions, chacune avec leur propre classloader, mais nous ajoutons maintenant la capacité de décharger dynamiquement les parties d'un embrochable qui dépendent des autres.
Pendant qu'elle s'avère, quand A embrochable fournit une interface que B embrochable fournit une exécution pour, le B embrochable ClassLoader (par la délégation au classloader d'A) tient une serrure sur la classe d'exécution elle-même. Même après nous annulons dehors le classloader dans A embrochable (si nous essayons de décharger A), le classloader du b garde une serrure sur A en raison de la classe d'interface que la classe de l'exécution du b garde une serrure dessus. Fondamentalement vous avez ceci :
pluginAInterface d'interface {}
le pluginBImpl de classe met en application le pluginAInterface {}
chacun est chargé par un classloader différent. Une fois utilisé, le classloader du b embrochable voit ce pluginAInterface d'instruments de pluginBImpl. Il commence dans le classloader du b embrochable le recherchant. Il ne peut pas le trouver là (parce que la classe de pluginAInterface est dans le classpath du classloader d'A embrochable). Le moteur embrochable délègue la consultation au classloader d'A embrochable trouver le code de byte pour cette classe de pluginAInterface. Il a trouvé là, ainsi le classloader « charges » d'A embrochable le bytecode, mais le classloader du b embrochable « voit » le bytecode en déléguant au commencement à A pour le trouver. Une fois trouvé, classloader établis dans des antémémoires le classloader : l'indicateur de classe (la signification, le classloader ET la classe composent une sorte de « clef » comme indicateur au bytecode réel dans la mémoire) ainsi ce plus les besoins de déléguer à l'A. MAIS, le grand problème est que la classe de pluginBImpl le maintient est de posséder la liste d'interfaces qu'elle met en application, principalement à leur référence de classe. La mauvaise chose au sujet de ceci est là n'est aucune manière de placer ceci pour annuler au temps d'exécution !
Ainsi notre tour est d'employer un deuxième classloader dans un embrochable pour permettre chaque interface mise en application par des autres embrochables pour l'avoir est de posséder le classloader ainsi nous pouvons jeter celui-là pour obtenir le rechargement/déchargeant pour travailler.
Il est un peu rusé, mais il fait le tour. Les issues probablement toujours plus cachées nous n'avons pas trouvé par hasard encore.
18 mars 2005 à 3:00 AM
Lukka @Goldy oui. Vous devriez pouvoir à. Toutefois je n'ai pas employé URLClassLoader de cette fa4con, ainsi moi ne suis pas sûr s'il en fait dur-à-enlever des références. Je devine qu'une solution de transitoire est en règle
BTW : J'apprécie votre emplacement.
mercis de @Kevin du commentaire très instructif.
19 mars 2005 à 2:54 AM
Goldy Lukka,
Le tour à employer URLClassLoader pour recharger ou décharger des dossiers de .jar veille qu'AUCUN autre code ne met en référence les classes l'unes des dans le dossier de .jar. Il est difficile contrôler des dépendances. Nous sommes allés à de grandes douleurs pour essayer de résoudre déchargeons/recharges avec l'issue des connexions selon une un autre. Nous faisons toujours se produire des problèmes dans beaucoup de cas la faire. Dans certains cas, les lotisseurs des connexions juste doivent se rendre compte que s'ils veulent faire leur aussi dynamique embrochable comme possible, ils vraiment doivent le développer de telle manière qu'ils nettoient correctement toutes les références qu'ils ont sur d'autres classes embrochables.
Si votre dossier de .jar ajoute juste des réalisations pour indiquer, les applications d'un noyau connectent api, vous devraient pouvoir l'enlever facilement. Comme nous avons découvert, une classe implemting garde une référence (serrure) sur l'interface qu'elle met en application. Ainsi la classe dans votre dossier de .jar garderait la référence à l'interface, qui est correcte, vous l'annulent simplement dehors et/ou annulent le classloader qui a chargé le .jar et vous êtes très bien. Si cependant le dossier de .jar fournit les interfaces dont d'autres classes (peut-être à partir d'autres dossiers de .jar) se servent, cela devient plus difficile. N'importe quelle classe en dehors de du classloader qui a chargé le dossier de .jar se servant de n'importe quelle classe de l'intérieur du .jar chargé doit également être déchargée. Encore, se rapportant à notre moteur, elle commence une réaction en chaîne de décharger les événements il peut être difficiles contrôler que. Nous avons résolu le problème en ayant deux exemples de classloader par embrochable. Un qui manipule les interfaces qui sont mises en application par d'autres classes embrochables, et un pour le reste des classes. Il n'est pas joli, mais jusqu'ici cela fonctionne. Nous expérimentons toujours pour faire à ceci un meilleur processus.
22 mars 2005 à 7:35 P.M.
Kevin,
Il est vrai que vous ne puissiez pas annuler la référence à la classe d'interface (Class#getInterfaces ()), si c'était possible il signifierait que vous enlevez l'interface dans le code de byte au temps d'exécution, de :
la classe publique MyTestImpl met en application TestImpl
{
}
à
classe publique MyTestImpl
{
}
Le même est vrai pour des superclasses.
23 mars 2005 à 6:23 P.M.
c'est la grande information qui comment les connexions sont des travaux. Peux j'avoir le code le plus simple possible du chargeur fait sur commande de classe. Finalement le chargeur fait sur commande de classe est des nees à charger par le classloader de défaut ou pas ? Si tellement alors I pourra voir au classloader dans le callgraph d'un tel genre de programme ?
1er avril 2005 à 6:02 AM
@Sandip pourquoi ne pas employer l'URLClassLoader ? Il y a également un code de ClassLoader d'échantillon fourni dans des cours d'instruction de Java.
11 septembre 2006 à 11:39 AM
Merci pour l'information.
Je lis quelque chose sur l'Internet que je pense est important pour certains ici :
Deux classes ne sont pas du même paquet si elles sont chargées par différents objets de ClassLoader !
Disons-vous ont un paquet avec deux classes, on est public et l'autre paquet-privé. Celles-ci devraient être chargées par le même objet de ClassLoader (ou sous-classe). Si vous vous n'obtenez pas une erreur d'exécution quand la classe publique essaye d'accéder à la classe paquet-privée.
Ainsi si vous prévoyiez de faire un nouvel objet de ClassLoader pour chaque classe, envisagez d'employer un objet de ClassLoader pour chaque paquet. L'autre option est de faire à toutes les classes le public.