Hoe te om de Klasse van Java leeg te maken
Ik ben meerdere keren gesteld deze vraag. Onlangs stelde Xyling de zelfde vraag in zijn blog. Zo dacht ik een eenvoudige verklaring in orde kan zijn.
Om een klasse leeg te maken moet u een douane tot stand brengen classloader en de klasse laden gebruikend het. De kater doet het en doet dat JRun. U kunt in de code van de Kater bij een voorbeeld kijken.
Nadat u met de klasse wordt gedaan moet u alle verwijzingen naar de klasse evenals naar de klassenlader vrijgeven door de variabelen opnieuw toe te wijzen of nietig te verklaren hen te plaatsen.
Dan of wacht op System.gc () om de klasse leeg te maken of u roept het direct binnen een lijn tot niet meer bytes kunnen worden bevrijd. nochtans normaal roepend doet het tweemaal de truc.
Nota: U kunt geen één enkele klasse leegmaken. U moet classloader samen met het leegmaken. Zo duidelijk is het Systeem classloader niet geschikt voor deze taak.
Nota 2: Zo Worden de jsp- pagina's herladen dynamisch everytime u veranderen de code. En ja is dat waarom de eerste keer veel duurt langer om verdere tijden dan te laden.
Filed onder hoe te, de Software van Java, Technologie | 
|
RSS 2.0 | 
E-mail dit Artikel
U kunt ook van houden te lezen |
Voeg aan Favorieten Technorati toe
15 maart, 2005 bij 6:31 p.m.
Hallo,
Dank u zeer voor deze informatie.
Let op als ik hier mijn vraag zelf uitbreid? Eigenlijk, laad ik mijn klassen door URLClassLoader. En over het algemeen laad ik de dossiers van de KRUIK door URLClassLoader. Nu wil ik dat dit dossier van KRUIK wordt leeggemaakt. Kan ik uw logica tot URLClassLoader voor de dossiers van de KRUIK ook uitbreiden?
15 maart, 2005 bij 6:33 p.m.
Dank u.
15 maart, 2005 bij 6:41 p.m.
Eigenlijk, is de JSP eerste-ladingstijd niet alleen toe te schrijven aan de klasse die wordt herladen, (het laden van een klasse van bytecode duurt dat niet lang, als het Java zou zijn een langzamer deed dan het is; -). Een significantere hoeveelheid tijd wordt doorgebracht producerend bytecode, aangezien een verandering in de bron JSP eerst in de bron van Java moet worden omgezet, en toen binnen aan byte-code, die dan door ClassLoader kan worden geladen. Zo, voeg toe twee ontleden/cycli aan één bytelading produceren
16 maart, 2005 bij 4:28 p.m.
Als u in het zien van een interessante draai bij het dynamische herladen van klassen geinteresseerd bent, controleer de bron in onze pluginmotor in http://www.platonos.org. Wij niet alleen laden plugins, elk met hun eigen classloader, maar wij nu voegen de capaciteit toe gedeelten van een plugin dynamisch om leeg te maken die van een andere afhankelijk zijn.
Aangezien het blijkt, wanneer plugin A een interface verstrekt dat plugin B een implementatie voor verstrekt, houdt plugin B ClassLoader (door delegatie aan classloader van A) een slot op de implementatieKlasse zelf. Zelfs nadat wij uit classloader in plugin A (als wij proberen om A) leeg te maken nietig verklaren, houdt B's classloader een slot op A wegens de interfaceKlasse dat de de implementatieklasse van B een slot houdt. Fundamenteel hebt u dit:
interface pluginAInterface {}
de klasse pluginBImpl voert pluginAInterface uit {}
elk wordt geladen door een verschillende classloader. Wanneer gebruikt, plugin ziet B's classloader dat pluginBImpl pluginAInterface uitvoert. Het begint in plugin B's classloader zoekend het. Het kan niet het daar vinden (omdat de pluginAInterfaceKlasse in pluginA's classloader classpath is). De afgevaardigden van de pluginmotor de raadpleging aan pluginA's classloader om de bytecode voor deze pluginAInterfaceKlasse te vinden. Het heeft daar gevonden, zodat plugin laadt classloader van A bytecode, maar plugin ziet B's classloader bytecode door aanvankelijk aan A om het af te vaardigen te vinden. Vond eens, een classloader die in geheim voorgeheugenopslag classloader wordt gebouwd: de klassen wijzer (het betekenen, classloader EN de klasse maken omhoog een soort sleutel als wijzer aan daadwerkelijke bytecode in geheugen) zodat het vereist niet meer aan afgevaardigde aan A. MAAR het grote probleem is dat de pluginBImplKlasse handhaaft het eigen lijst van interfaces is het, hoofdzakelijk hun verwijzing van de Klasse ten uitvoer legt. Het slechte ding over dit is daar is geen manier om dit te plaatsen bij runtime nietig te verklaren!
Zo moet onze truc tweede classloader binnen een toe te staan plugin gebruiken elke interface die door een andere te hebben plugin wordt uitgevoerd het eigen classloader is zodat kunnen wij dat verwerpen om het herladen/het leegmaken te krijgen om te werken.
Het is een netelig beetje, maar het doet de truc. Waarschijnlijk nog meer verborgen kwesties zijn wij niet over nog gekomen.
18 maart, 2005 bij 3:00 am
@Goldy Lukka ja. U zou moeten kunnen aan. Nochtans heb ik URLClassLoader op deze wijze gebruikt, zodat ben ik niet zeker als het geen heeft verwijzingen hard-aan-verwijderen. Ik veronderstel een aaroplossing in orde is
BTW: Ik geniet van uw plaats.
@Kevin Dank voor de zeer informatieve commentaar.
19 maart, 2005 bij 2:54 am
Goldy Lukka,
De truc aan het gebruiken van URLClassLoader om .jar dossiers te herladen of leeg te maken zorgt ervoor dat GEEN andere code om het even welke klassen binnen het .jar dossier van verwijzingen voorziet. De gebiedsdelen zijn moeilijk te leiden. Wij zijn naar grote pijnen gaan proberen op te lossen elkaar leegmaken/herladen met de kwestie van plugins afhankelijk van. Wij hebben problemen die nog in veel gevallen het maken gebeuren. In sommige gevallen, moeten zich de ontwikkelaars van plugins enkel ervan bewust zijn dat als zij hun plugin zo dynamisch mogelijk willen maken, zij werkelijk het moeten ontwikkelen zodanig dat zij om het even welke verwijzingen behoorlijk schoonmaken die zij op andere pluginklassen hebben gehad.
Als uw .jar dossier enkel te zeggen implementaties toevoegt, zou een interface API van kerntoepassingen, u het moeten kunnen gemakkelijk verwijderen. Zoals wij ontdekten, houdt een implemting klasse een verwijzing (slot) op de interface het uitvoert. Zo zou de klasse in uw .jar dossier ref aan de interface, die o.k. is, u nietig verklaart het eenvoudig uit en/of nietig verklaart classloader houden die .jar laadde en u bent fijn. Als nochtans het .jar dossier interfaces verstrekt dievan andere klassen (misschien van andere .jar dossiers) gebruik maken, wordt dat moeilijker. Om het even welke klasse buiten classloader die het .jar dossier gebruik makend van om het even welke klasse van binnenuit geladen .jar laadde moet ook worden leeggemaakt. Opnieuw, verwijzend naar onze motor, begint het een kettingreactie van het leegmaken gebeurtenissen die moeilijk kan zijn te leiden. Wij losten het probleem door het hebben van twee classloaderinstanties per op plugin. die de interfaces behandelt die door andere pluginklassen, en voor de rest klassen worden uitgevoerd. Het is niet mooi, maar tot zover werkt het. Wij experimenteren nog om tot dit een beter proces te maken.
22 maart, 2005 bij 7:35 p.m.
Kevin,
Het is waar dat u niet de verwijzing naar de interfaceklasse (Class#getInterfaces () kunt nietig verklaren), als dit mogelijk was zou het betekenen dat u de interface in de bytecode bij runtime, uit verwijdert:
de openbare instrumenten TestImpl van klassenMyTestImpl
{
}
aan
openbare klasse MyTestImpl
{
}
Het zelfde is waar voor superclasses.
23 maart, 2005 bij 6:23 p.m.
het is grote informatie dat hoe plugins de werken zijn. Kan ik de eenvoudigste mogelijke code van de lader van de douaneklasse hebben. Uiteindelijk moet de lader van de douaneklasse nees door het gebrek of niet worden geladen classloader? Als zo dan ik aan classloader in callgraph van dergelijk soort programma zal kunnen zien?
1 april, 2005 bij 6:02 am
@Sandip waarom URLClassLoader niet gebruiken? Ook is er een code van steekproefClassLoader die in de Leerprogramma's van Java wordt verstrekt.
11 september, 2006 bij 11:39 am
Dank voor de informatie.
Ik las iets op Internet dat ik denk hier voor sommige mensen belangrijk is:
Twee klassen zijn niet van het zelfde pakket als zij door verschillende voorwerpen ClassLoader worden geladen!
Zeg u een pakket met twee klassen hebt, is men openbaar en pakket-privé andere. Deze zouden door het zelfde (of de subklasse) moeten worden geladen voorwerp ClassLoader. Als u u geen runtime fout krijgt wanneer de openbare klasse probeert om tot de pakket-privé klasse toegang te hebben.
Zo als u van plan was om een nieuw voorwerp ClassLoader voor elke klasse te maken, denk na gebruikend één voorwerp ClassLoader voor elk pakket. De andere optie moet al klassenpubliek maken.