2015-12-23 20 views
5

Durante la profilazione della mia applicazione mi sono imbattuto in un comportamento strano - il thread DestroyJavaVM è SEMPRE in esecuzione - il 100% delle volte.Thread DestroyJavaVM SEMPRE in esecuzione

enter image description here Dopo aver fatto un po 'di ricerca sul tema, su cui non c'è quasi più preziose informazioni on-line, tutto quello che ho capito è che questa discussione dovrebbe unload the JVM upon exit.

Se è questo il caso, perché questo thread in RUNNING indica il 100% del tempo dal primo momento in cui avvio la mia applicazione? Non consuma risorse preziose e quindi può causare un OutOfMemoryError (come a volte capita)?

Esiste un riferimento ufficiale a ciò che fa effettivamente questo thread e che cosa attiva la sua inizializzazione?

Grazie

+0

È più probabile che altri thread causino il 'OOME'. Non inizierei dal sospetto meno ovvio. Hai profilato i tuoi thread di applicazioni per l'utilizzo della memoria? Questo sarebbe l'approccio semplice per il debug dei tuoi misteriosi 'OOME's. – Kayaman

+0

10 volte per la risposta. Naturalmente ho usato altre misure per scoprire perché ottengo l'OOME (che, BTW è un errore "GC Overhead Limit exceeded", causato da un elevato utilizzo della CPU), ma senza successo. Questa è la mia ultima risorsa. Questo thread è molto sospetto e voglio sapere quali attività ha in esecuzione il 100% delle volte. – KidCrippler

risposta

31

Ciò accade perché la maggior parte delle applicazioni vengono eseguite in thread.

Tutte le app POJO iniziano invocando il metodo main. Nel suo caso più semplice questo metodo farà tutto il lavoro, creando oggetti, chiamando metodi, ecc. Una volta completato main, la JVM verrà chiusa utilizzando un thread DestroyJavaVM che attende il completamento di tutti i thread non daemon prima di eseguire il proprio lavoro . Questo per garantire che tutti i thread creati vengano completati prima che la JVM venga demolita.

Un'app con una GUI, tuttavia, viene normalmente eseguita come un numero di thread. Uno per la visione di eventi di sistema come eventi di tastiera o mouse. Uno per il mantenimento delle finestre e del display ecc. Il metodo main di questo tipo di app probabilmente avvia solo tutti i thread richiesti ed esce. Crea ancora il thread DestroyJavaVM ma ora tutto ciò che fa è attendere che tutti i thread creati finiscano prima di abbattere la VM.

Di conseguenza, qualsiasi app che crea discussioni e fa affidamento esclusivamente sulla loro funzionalità avrà sempre un thread DestroyJavaVM in attesa che finisca. Dal momento che tutto ciò che sta facendo è join in tutti gli altri thread in esecuzione non consuma risorse.

+0

10 volte per la risposta. La mia app non ha alcuna GUI. Sto istanziando molti thread, però, e sicuramente mi baso sulla loro funzionalità. Ha qualcosa a che fare con il thread DestroyJavaVM? Cosa fa scattare la sua inizializzazione? Se ho capito bene, tu dici che anche se il thread è mostrato come RUNNING, in realtà è ASPETTANDO? – KidCrippler

+3

@KidCrippler - Viene creato e avviato dopo le uscite 'main'. Vedi [Thread.join()] (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Thread.java#Thread.join%28long % 29) per il motivo per cui si trova in uno stato 'Running' - usa' wait (0) 'in un ciclo stretto. – OldCurmudgeon

+0

Questa è semplicemente una risposta fantastica. Grazie per averlo scritto. Sono venuto qui a caso a curiosare, non cercavo nessuna soluzione, ma la tua risposta mi ha indotto a votare. :) –

Problemi correlati