2012-06-29 15 views
5

Chciałbym sprawdzić, czy moje rozumowanie jest prawidłowe.wątek java stan

Przede wszystkim powinienem podać kilka szczegółów na temat problemu próbuję rozwiązać. Wątek (część programu) wykonuje następujące rzeczy:

  1. to rozpoczyna się
  2. wywołuje Thread.Sleep (20ms)
  3. wywołuje Getin metoda()
  4. próbuje uzyskać blokadę (lock.lock())
  5. jeśli pomyślnie dostaje blokadę wywołuje Thread.Sleep (100ms)
  6. jeśli blokada nie jest dostępny wywołuje waitingCond.await()
  7. po wywołaniu Thread.Sleep (100ms) to wzywa lock.unlock()
  8. wywołuje metodę inną getout()
  9. to kończy (thread.join())

Biorąc pod uwagę, że po to mój zgadywać o stanie Temat:

  1. READY TO RUN stan
  2. TIMED WAITING stan
  3. WAITING stan
  4. WAITING stan
  5. BLOCKED stan
  6. WAITING stan
  7. WAITING stan
  8. TERMINATED państwowe

Dzięki

+0

Czy jest jakiś moment, w którym faktycznie znajduje się w stanie działania? :) –

+0

@LukasKnuth Zakłóciłeś numerację OP, gdzie 5.1 był opcjonalnym krokiem podrzędnym. Myślisz, że tak jest lepiej? –

+0

To dość nudne dla wątku ... I: Nie dałeś nam pytania. – brimborium

Odpowiedz

8

Przede wszystkim, należy opisać READY TO RUN państwo jest faktycznie RUNNABLE. Dla mojej pracy licencjackiej stworzyłem wykres przejściowy pokazujący różne stany nici i kiedy powinny się zmienić. Nie opisali semantykę getIn(), więc myślę, że to jest właśnie sposób losowy.

Jeśli wątek jest wykonywany kod, na przykład na swoich metod getIn() lub getOut() jest RUNNABLE i nie WAITING. BLOCKED jest w rzeczywistości tylko bardzo krótkim stanem przejściowym, który jest zawsze wprowadzany, gdy wątek próbuje odebrać blokadę. Jeśli blokada nie jest dostępny nitka wciąż jest zablokowany i nie można wykonać kolejną akcję, jak sugerują w punkcie 6. Ponadto nie można wywołać metodę po wywołaniu Thread.sleep() musi czekać, aż upłynie czas.

chciałbym skorygować w następujący sposób:

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

Thread State Transitions

Zastrzeżenie: Nie ma gwarancji na przejściach. Może się nawet zdarzyć, że sprzedawca JVM zdecyduje się wdrożyć mechanikę bazową w inny sposób, na przykład może wdrożyć blokowanie przez oczekiwanie na spin.

Jeśli chcesz zagłębić się w ten temat, skorzystaj z Profila, aby poznać stany swojego wątku. Napisałem jeden z moich własnych, aby wykryć te stany: Java Concurrency Profiler, ale są tam również inne, na przykład VisualVM lub YourKit.