2013-08-29 36 views
5

So che gerarchia di caricatori di classe in Java è:Perché sono necessari più caricatori di classe?

classe 1.Bootstrap loader (in codice nativo) classe
2. Estensione loader (sun.misc.Launcher$ExtClassLoader)
3. classe System loader (sun.misc.Launcher$AppClassLoader class)
4 Caricatori di classi personalizzate (ad es. Server di applicazioni, classloader di auricolari, classloader di guerra)

Non è chiaro per me perché sono necessari ulteriori programmi di caricamento classe figlio. Potrei capire la necessità di un programma di caricamento classi "pure java" dopo quello nel codice nativo.
Ho qualche idea di possibili motivi ma qualcuno può fornirmi una spiegazione chiara per questo comportamento/necessità di gerarchie di caricatori di classi?
In generale, ma applicabile anche per j2ee.

risposta

4

I programmi di caricamento di classe sono utili per fornire una varietà di comportamenti e per proteggere diversi programmi Java eseguiti nella stessa VM gli uni dagli altri. Ci sono tre categorie principali che vengono in mente:

  • I programmi di caricamento di classe possono implementare il processo di caricamento delle classi in modo diverso. Ad esempio, potresti avere un classloader che recupera il bytecode per una classe da un server e quindi lo installa nella JVM, oppure potresti avere un classloader che in realtà è generates the bytecode on the fly invece di leggerlo da un file.
  • I programmi di caricamento classe possono creare partizioni all'interno di una singola JVM in modo che i diversi "alberi" di codice possano avere copie diverse di classi con lo stesso nome. Un esempio comune di questo è un contenitore di servlet come Tomcat, in cui potrebbero essere installati più war s che hanno tutte versioni diverse di una libreria (ad esempio, Apache Commons-Lang). OSGi utilizza anche questo approccio per garantire che ogni bundle possa accedere solo alle classi specificatamente richieste e non possa "perdere" l'API.
  • I programmi di caricamento classi possono essere utilizzati per implementare politiche diverse su quando raccogliere automaticamente le classi stesse. L'uso del classloader predefinito mantiene le classi in giro indefinitamente, portando agli errori di PermGen temuti; un'applicazione che utilizzava molte classi temporanee (forse quelle generate al volo) potrebbe volere assicurarsi che siano state liberate quando non sono più necessarie utilizzando i classloader usa e getta.
+0

I programmi di caricamento di classe sono tenuti a mantenere tutte le classi caricate, a condizione che sia raggiungibile anche il 'ClassLoader'.Se vuoi che una classe sia collezionabile in precedenza, crea una nuova istanza di 'ClassLoader' appositamente per essa. –

+0

Hai ragione; la modifica. – chrylis

0

Immagino che i classloader in uso dipendano dallo specifico server delle applicazioni. Ecco la documentazione per Tomcat class loaders.

In Tomcat, hanno essenzialmente creato diversi caricatori di classe che caricano le classi da posizioni diverse. Ad esempio, il caricatore di classi comuni carica la libreria condivisa da $CATALINA_HOME/lib. Ogni programma di caricamento classi di app Web caricherà le classi dalla rispettiva directory WEB-INF.

Quindi la necessità di caricatori di classe deriva principalmente dalla necessità di caricare da posizioni diverse, con alcune regole di precedenza (ad esempio la classe da WEB-INF ha la precedenza su CATALINA_HOME/lib). Inoltre, consentono di caricare diverse versioni di una classe in caricatori di classi differenti. Ad esempio, due app Web possono utilizzare due diverse versioni di Log4j in questo modo.

Il server di altre applicazioni potrebbe avere una gerarchia di caricatore di classi diversa, ma gli stessi motivi si applicano anche a loro.

Problemi correlati