2012-06-29 21 views
5

Me gustaría comprobar si mi razonamiento es correcto.thread state java

En primer lugar, debo proporcionar algunos detalles sobre el problema que estoy tratando de resolver. Un hilo (parte de un programa) hace las siguientes cosas:

  1. Comienza
  2. que llama Thread.sleep (20 ms)
  3. que llama GETIN método()
  4. se trata de obtener un bloqueo (lock.lock())
  5. si recibe correctamente el bloqueo que llama Thread.sleep (100 ms)
  6. si el bloqueo no está disponible se llama waitingCond.await()
  7. después de llamar Thread.Sleep (100 ms) eso pide lock.unlock()
  8. que llama a otro método getout()
  9. Finaliza (Thread.Join())

Dado que, la siguiente es mi adivinar sobre el estado hilo:

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

Gracias

+0

¿Hay algún momento en el que realmente se encuentre en estado de ejecución? :) –

+0

@LukasKnuth Has interrumpido la numeración de OP donde 5.1 era un paso subordinado opcional. ¿Crees que es mejor así? –

+0

Eso es bastante aburrido para el hilo ... Y: No nos has hecho una pregunta. – brimborium

Respuesta

8

En primer lugar, el estado que usted describe con READY TO RUN es en realidad RUNNABLE. Para mi tesis de licenciatura, había creado un gráfico de transición que mostraba los diferentes estados de los hilos y cuándo deberían cambiar. No ha descrito la semántica de getIn(), así que supongo que es solo un método aleatorio.

Si el hilo está ejecutando código, por ejemplo, sobre sus métodos de getIn() o getOut() es RUNNABLE y no WAITING. BLOCKED es en realidad un estado de transición muy corto, que siempre se ingresa cuando un hilo intenta reclamar un bloqueo. Si el bloqueo no está disponible, el hilo sigue bloqueado y no puede ejecutar otra acción como implica en el paso 6. Además, no puede invocar un método después de llamar al Thread.sleep(), tiene que esperar hasta que transcurra el tiempo.

Me corregirla de la siguiente manera:

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

Thread State Transitions

Negación: no hay ninguna garantía para las transiciones. Incluso podría ser que un vendedor de JVM decida implementar la mecánica subyacente de otra manera, por ejemplo, podría implementar el bloqueo mediante spin-waiting.

Si desea profundizar en este tema, use un Analizador para conocer los estados de su hilo. He escrito una de mi propia para detectar aquellos estados: Java Concurrency Profiler, pero hay otros por ahí, así, por ejemplo VisualVM o YourKit.