5

私の推論が正しいかどうかを確認したいと思います。

まず、解決しようとしている問題についていくつか詳しく説明します。スレッド（プログラムの一部）は次のことを行います。

  1. 始まる
  2. Thread.sleepを呼び出します（20ms）
  3. getIn（）メソッドを呼び出します
  4. ロックを取得しようとします（lock.lock（））
  5. ロックが正常に取得されると、Thread.sleep（100ms）が呼び出されます。
  6. ロックが利用できない場合は、waitingCond.await（）を呼び出します。
  7. Thread.sleep（100ms）を呼び出した後、lock.unlock（）を呼び出します。
  8. 別のメソッドgetOut（）を呼び出します
  9. 終了します（thread.join（））

それを考えると、以下はスレッドの状態についての私の推測です：

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

ありがとう

4

1 に答える 1

10

まず、あなたが記述した状態READY TO RUNは実際にはRUNNABLEです。私の学士論文では、さまざまなスレッドの状態と、いつ変更する必要があるかを示す遷移グラフを作成しました。のセマンティクスについて説明していないgetIn()ので、単なるランダムな方法だと思います。

スレッドがコードを実行している場合 (たとえば、メソッドの ongetIn()またはgetOut()is RUNNABLEand not WAITING. BLOCKED実際には非常に短い遷移状態にすぎず、スレッドがロックを要求しようとすると常に遷移状態に入ります。ロックが利用できない場合、スレッドはブロックされたままになり、手順 6 で暗示しているように別のアクションを実行できません。また、メソッドを呼び出した後Thread.sleep()、時間が経過するまで待機する必要があります。

私なら次のように修正します。

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

スレッドの状態遷移

免責事項: 遷移に対する保証はありません。JVM ベンダーが、たとえばスピン待機によるブロッキングを実装するなど、別の方法で基盤となるメカニズムを実装することを決定することさえあるかもしれません。

このトピックをさらに深く掘り下げたい場合は、プロファイラーを使用してスレッドの状態を調べてください。私はこれらの状態を検出するために独自のものを作成しました: Java Concurrency Profilerですが、 VisualVMやYourKitなど、他にもあります。

于 2012-07-02T23:04:09.153 に答える