2012-06-29 13 views
5

Vorrei verificare se il mio ragionamento è corretto.thread state java

Prima di tutto, dovrei fornire alcuni dettagli sul problema che sto cercando di risolvere. Un filo (parte di un programma) fa le seguenti cose:

  1. Si inizia
  2. chiama Thread.sleep (20ms)
  3. chiama GETIN il metodo()
  4. si cerca di ottenere un blocco (lock.lock())
  5. se ottiene con successo il blocco che chiama Thread.sleep (100 ms)
  6. se il blocco non è disponibile si chiama waitingCond.await()
  7. dopo aver chiamato Thread.Sleep (100 ms) esso chiede lock.unlock()
  8. si chiama un metodo getout()
  9. essa termina (Thread.join())

Dato che, il seguente è il mio indovinare sullo stato del filo:

  1. READY TO RUN stato
  2. TIMED WAITING stato
  3. WAITING stato
  4. WAITING stato
  5. BLOCKED stato
  6. WAITING stato
  7. WAITING stato
  8. TERMINATED statali

Grazie

+0

C'è un momento in cui è effettivamente in esecuzione? :) –

+0

@LukasKnuth Hai interrotto la numerazione dell'OP in cui 5.1 era un passaggio subordinato facoltativo. Pensi che sia meglio così? –

+0

Questo è piuttosto noioso per il thread ... E: non ci hai fatto una domanda. – brimborium

risposta

8

Prima di tutto, lo Stato si descrive con READY TO RUN è in realtà RUNNABLE. Per la mia tesi di laurea ho creato un grafico di transizione che mostra i diversi stati del filo e quando dovrebbero cambiare. Non hai descritto la semantica di getIn(), quindi immagino sia solo un metodo casuale.

Se il thread è in esecuzione il codice, ad esempio in materia dei tuoi metodi getIn() o getOut() è RUNNABLE e non WAITING. BLOCKED è in realtà solo uno stato di transizione molto breve, che viene sempre immesso quando un thread tenta di richiedere un blocco. Se il blocco non è disponibile, il thread continua a essere bloccato e non può eseguire un'altra azione come implicito nel passaggio 6. Inoltre, non può richiamare un metodo dopo aver chiamato Thread.sleep() che deve attendere fino al termine del tempo.

vorrei correggerlo seguente modo:

  1. RUNNABLE
  2. TIMED WAITING
  3. RUNNABLE
  4. BLOCKED
  5. TIMED WAITING
  6. BLOCKED
  7. RUNNABLE
  8. TERMINATED

Thread State Transitions

Disclaimer: Non c'è alcuna garanzia per le transizioni. Potrebbe anche darsi che un venditore JVM decida di implementare la meccanica sottostante in un altro modo, ad esempio potrebbe implementare il blocco in attesa di rotazione.

Se si desidera approfondire questo argomento, utilizzare un Profiler per scoprire gli stati del thread. Ho scritto uno dei miei per rilevare quegli stati: Java Concurrency Profiler, ma ce ne sono altri anche lì, ad esempio VisualVM o YourKit.