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.