2011-10-07 12 views
30

Sto eseguendo l'applicazione web java utilizzando Server Hibernate e Glassfish. Sto ottenendoErrore spazio permGen - Server Glassfish

java.lang.OutOfMemoryError: PermGen space eccezione quando dopo averlo distribuito più volte.

Ho provato -XX:MaxPermSize=128M nelle variabili di ambiente, ma non funziona.

+0

È questo che stai cercando: http://stackoverflow.com/questions/1996088/java-class-permgen-memory-leak-web-applications-generic-solution – Raedwald

risposta

37

Questo è perdita di memoria di classe loader. Ogni volta che si ridistribuisce l'applicazione, viene creato un nuovo classloader per esso e tutte le classi dell'applicazione vengono caricate nuovamente. Questo consuma memoria nello spazio dei perm gen.

Il vecchio classloader e tutte le sue classi caricate devono essere raccolte da dati inutili, altrimenti alla fine si verificherà uno spazio PermGen OOME dopo la distribuzione di più volte. Questo non funziona se un oggetto caricato da un classloader esterno contiene un riferimento a qualsiasi oggetto caricato dal vecchio classloader. This article fornisce una buona spiegazione del problema.

Generalmente, le perdite di classloader sono difficili da analizzare e talvolta difficili da risolvere. Per scoprire perché i vecchi classloader non sono raccolti, devi usare un profiler. In JProfiler, utilizzare il walker dell'heap, selezionare gli oggetti del classloader glassfish e utilizzare la vista dei riferimenti in entrata per verificare i percorsi delle root del garbage collector.

La classe del caricatore classe è denominata org.apache.servlet.jasper.JasperLoader. Ecco uno screenshot di una situazione normale, in cui il caricatore di classi viene tenuto solo da istanze live di oggetti caricati.

enter image description here

Nella tua situazione, si dovrebbe vedere i riferimenti da oggetti esterni. Un'altra causa comune di perdita di un classloader nei contenitori Web è un thread in background non arrestato. Google Guice, ad esempio, ha un tale bug in 3.0.

(Disclaimer: la mia azienda sviluppa JProfiler)

5

Questo problema si verifica con la distribuzione iterativa molte volte. Ho affrontato questo molte volte. Si prega di fare riferimento al di sotto di collegamento JIRA per il bug GlassFish:

http://java.net/jira/browse/GLASSFISH-587

+1

Hai visto l'anno di quel bug report ?! –

46

Per risolvere questo problema (in OS basato su Linux) non segue

1) aumento di memoria (in modo che questo problema non arrivano di frequente) da configurazione "dominio.xml" in

/GlassFish/dominio/domain1/config

ricerca di

<jvm-options>-XX:MaxPermSize=

set it to higher value eg- 198m or 256m

2) uccidere il processo di pesci vetro per liberare la porta su cui era in esecuzione (nel mio caso era 8686) terminale aperto (in os basato su Linux) e tipo -

sudo netstat -npl | grep 8686

questo si tradurrà in qualcosa di simile ..

tcp6 0 0 :::8686 :::* LISTEN 3452/java

successivo utilizzo

kill -9 3452 uccidere quel processo (3452 in questo caso)

Ora provare ad avviare glassfish, dovrebbe iniziare.

+0

grazie signore! molto bene! –

9

Se si utilizza Windows, provare ad eliminare il processo glassfish (java.exe * 32) con Task Manager e quindi riavviare il server.

+0

Questo è perfetto –

Problemi correlati