2014-12-10 27 views
48

Qualcuno può spiegarmi la differenza tra Sleeping, Wait, Park e Monitor stati thread in VisualVM.VisualVM - Stato thread

enter image description here

Questo è quello che ho trovato:

Running: discussione è ancora in esecuzione.
Sleeping: filetto sta dormendo (metodo yield() è stato chiamato sull'oggetto filo)
Wait: filo è stato bloccato da un mutex o una barriera, ed è in attesa di un altro filo per togliere il blocco
Park: filetti parcheggiati sono sospeso fino a quando non viene loro concesso un permesso. Rimuovere dal parcheggio un filo di solito è fatto chiamando il metodo riprendi() sull'oggetto filo
Monitor: le discussioni sono in attesa di una condizione di diventare fedeli a riprendere l'esecuzione

Quello che non riesco a capire è stato parco, quello che in realtà sospende il filo? Come faccio a rilevare nel codice cosa ha causato il thread sospendere la sua esecuzione?

Qualcuno può guidarmi per favore in questo senso.

Grazie.

+0

Google è il tuo migliore amico: usalo! –

+1

Grazie! Aggiornerò la mia domanda con quello che ho trovato su google. –

risposta

29

Ho usato google e la prima pagina che è venuta fuori aveva un diagramma molto carino che descrive praticamente tutto ciò che serve/vuoi sapere. La prossima volta vale la pena provare google per questo tipo di domande.

enter image description here

1) Nuova

Il filo è nel nuovo stato se si crea un'istanza della classe Thread, ma metodo prima l'invocazione di start().

2) Runnable

La filettatura è in stato eseguibile dopo l'invocazione del metodo start(), ma lo scheduler filo non ha selezionato per essere il filo conduttore.

3) Esecuzione

Il filo in posizione di regime se lo scheduler thread è selezionato esso.

4) Timed attesa

attesa Timed è uno stato filo per un filo attesa con un tempo di attesa specificato. Un filo è nello stato di attesa a tempo dovuto chiamare uno dei seguenti metodi con un tempo di attesa positiva specificato:

  • Thread.sleep (sleeptime)
  • Object.wait (timeout)
  • Thread.join (timeout)
  • LockSupport.parkNanos (timeout)
  • LockSupport.parkUntil (timeout)

5) non Runnable (bloccato)

Questo è lo stato in cui il filo è ancora vivo, ma al momento non è idoneo alla pubblicazione.

6) Terminato

Un thread è in stato chiuso o morto quando la sua corsa() metodo termina.

Speriamo che questo risponda alla tua domanda :).

Parcheggio:

Disabilita il thread corrente per scopi di programmazione dei thread a meno che il permesso di è disponibile.

I thread vengono parcheggiati o sospesi se si desidera chiamarlo in questo modo perché non dispone dell'autorizzazione per l'esecuzione. Una volta concesso il permesso, il thread sarà non parcheggiato ed eseguito.

I permessi di LockSupport sono associati a thread (vale a dire il permesso viene dato a un determinato thread) e non si accumulano (cioè può esserci un solo permesso per thread, quando il thread consuma il permesso, scompare).

+0

Grazie per la risposta. Ci sono passato anche io, ma in qualche modo la mia domanda rimaneva ancora senza risposta. Potresti per favore ripassare la mia domanda? L'ho aggiornato. Sono particolarmente alla ricerca di una risposta w.r.t. lo stato del parco. –

+0

@AliShahAhmed ha aggiornato la mia risposta :) –

+0

grazie ancora per l'aggiornamento. Quindi, nello stato del parco, il thread sta aspettando che venga programmato o è in attesa di qualche condizione? –

19

VisualVM associa lo stato di thread Java (come descritto nel @ risposta di Maciej) allo stato presentato nella sua interfaccia utente come segue:

BLOCKED -> Monitor 
RUNNABLE -> Running 
WAITING/TIMED_WAITING -> Sleeping/Park/Wait (see below) 
TERMINATED/NEW -> Zombie 

Sleeping e Park sono casi specifici di (a tempo) di attesa:

Sleeping: specifically waiting in Thread.sleep(). 
Park:  specifically waiting in sun.misc.Unsafe.park() (presumably via LockSupport). 

(La mappatura viene eseguita in ThreadMXBeanDataManager.java.)

Una breve (e non autorevole) discussione dello stato del thread Java può essere trovato here.

cura di aggiungere:

È anche interessante notare che le discussioni blocco nelle chiamate a metodi nativi appaiono nella JVM RUNNABLE, e quindi sono segnalati da VisualVM come Running (e come consumare CPU 100%).