2

同期ブロックを実行しているスレッドがあり、その同期ブロックにアクセスしようとする別のスレッドがある場合。

  1. ブロックされたスレッドで Object.wait が自動的に呼び出されますか?

  2. また、 Object クラスでは、待機の定義は次のとおりです。

    public final native void wait(long timeout) throws InterruptedException;

これは、クラスで以下のような関数を手動で作成する必要があることを意味しますか? 私は多くの例を見てきました：

public void doWait(){
    synchronized(obj){
      while(!wasSignalled){
        try{
          obj.wait();
         } catch(InterruptedException e){...}
      }
      //clear signal and continue running.
      wasSignalled = false;
    }
  }

public void doNotify(){
    synchronized(obj){
      wasSignalled = true;
      obj.notify();
    }
  }
4

2 に答える 2

7

いいえ、Object::wait呼ばれません。wait/メカニズムは、notifyによって提供される基本的なロックの上にある追加のレイヤーsynchronizedです。またはを使用しsynchronizedなくても使用できます。waitnotify

基本的なsynchronizedメカニズムは、特定のオブジェクトに取り付けられたロックをロックおよびロック解除するという考え方に基づいています (ロックはモニターと呼ばれることもあります)。1 つのスレッドがロックをロックすると、それをロックしようとする別のスレッドがブロックされます。最初のスレッドがロックを解除すると、2 番目のスレッドがブロックを解除し、引き続きロックをロックします。

wait/メカニズムは、スレッドが保持しているロックを一時的に放棄する方法を提供します。notifyその間、ロックを保持している他のスレッドによってロックの再取得が制御されます。次のコードを検討してください。

public synchronized void first() {
    System.out.println("first before");
    wait();
    System.out.println("first after");
}

public synchronized void second() {
    System.out.println("second before");
    notify();
    System.out.println("second after");
}

あるスレッド、スレッド A が を呼び出しfirst、次に別のスレッド B が を呼び出しているとしますsecond。イベントのシーケンスは次のとおりです。

  1. A がロックを取得しようとする
  2. A がロックの取得に成功する
  3. A は System.out に「first before」を書き込みます
  4. B がロックの取得を試みる
  5. B はロックを取得できません。A がロックを取得しているため、ブロックされます。
  6. A が書き込みを終了し、呼び出しますwait。この時点で、Aはロックを解放し、代わりに待機を開始します。
  7. B はロックの取得に成功し、ブロックを解除します
  8. B は System.out に「秒前」を書き込みます。
  9. B が書き込みを終了し、呼び出します。notifyこれは B には影響しませんが、Aが待機を停止し、ロックを再取得しようとすることを意味します。
  10. Bがロックを取得しているため、Aはロックを取得できないため、ブロックされます
  11. B は System.out に「秒後」を書き込みます。
  12. B はメソッドを終了し、ロックを解除します
  13. A はロックの取得に成功し、ブロックを解除します
  14. A は続行し、System.out に「first after」を書き込みます。
  15. A はメソッドを終了し、ロックを解放します

これは長々と説明しましたが、実際には非常に単純なプロセスです。wait/notify呼び出しは、最初のスレッドが別のスレッドにロックを貸して使用できるようにするようなものです。

2 種類のブロッキングが行われていることを認識することが重要です。synchronizedまず、スレッドがブロックに入るとき(または呼び出しから戻ったときにブロックを再入力するとき) に、スレッドがロックを取得するのをブロックする方法wait。次に、 を呼び出した後wait、対応する によってブロック解除される前に、スレッドがブロックする方法notify。

私は、wait/notifyが別のスレッドにロックを貸すスレッドであると説明しました。これは私が考える方法であり、生産的な比喩だと思います。時事的に不気味な比喩を使うと、おそらくそれは吸血鬼が城に移動し、棺桶の中で眠りにつくようなものです. 彼が眠りにつくと、無実の観光客がやって来て、城を別荘として貸し出します。ある時点で、訪問者は地下室を探索し、棺桶を邪魔します。その時点で、吸血鬼は目を覚まし、城を取り戻したいと思っています. 観光客が恐怖で逃げたら、彼は家に戻ることができます。

とのような名前ではなく、 と という名前が付けられているwait理由は、これらが通常、スレッド間通信メカニズムを構築するために使用されるためです。そこでは、最初のスレッドによるロックの最初の貸し出しではなく、目覚めに重点が置かれます。 2番目のスレッドによるウェイターの。notifylendreturn

さて、最後に 2 番目の質問に移りますが、考えるべきことが 2 つあります。

1 つ目は、「誤ったウェイクアップ」の可能性です。セクション17.2.1 のネストされた箇条書きリストの奥にある小さなメモを参照してください。Java 言語仕様の待機:

[...] 実装による内部アクションのため、スレッドは待機セットから削除される可能性があります。推奨はされていませんが、実装で「偽のウェイクアップ」を実行すること、つまり待機セットからスレッドを削除して、明示的な指示なしに再開できるようにすることは許可されています。

つまり、スレッドは通常、通知された場合にのみウェイクアップしますが、通知されていないときにランダムにウェイクアップする可能性があります。waitしたがって、例とまったく同じように、条件変数のチェックを含むループで aを保護する必要があります。仕様が言うように：

この規定により、スレッドが待機している何らかの論理条件が保持される場合にのみ終了するループ内でのみ待機を使用するという Java コーディングの慣行が必要になることに注意してください。

2つ目は中断です。中断はランダムではありません。interrupt割り込みは、待機中のスレッドで他のスレッドが呼び出された場合にのみ発生します。これが発生すると、すぐにブロックを停止しInterruptedException、wait呼び出しをスローします。これまで見てきたこととは反対に、この例外をキャッチして再度待機するのは正しくありません。その理由は非常に単純です。誰かがinterruptあなたのスレッドに電話をかけてきたら、それはまさに彼らがあなたに電話してほしいからです。stop waiting! 代わりにスレッドが何をすべきかを正確に言うことは不可能ですが、通常のアプローチは、現在の作業を中止し、制御を呼び出し元に戻すことです。現在の作業が中止された後に呼び出し元が続行できない場合は、呼び出し元も中止する必要があり、適切な処理ができるレベルに達するまで呼び出しスタックを上に上げます。割り込みの正しい処理は、ここで扱うには大きすぎるテーマですが、チュートリアルの割り込みのサポートについて読むことから始め、可能であればJava Concurrency In Practiceを読んでください。

于 2013-11-04T11:15:48.880 に答える
2

Object.wait はブロックされたスレッドで自動的に呼び出されますか?

そうではありませんが、モニターロックでブロックされます。この仕組みの詳細については、ドキュメントを参照してください。とにかく、これが内部でどのように行われるかについての詳細は、実際には使用synchronizedには関係ありません。同期化されたブロックを一度に実行できるスレッドは 1 つだけであることを知っていれば、それを使用できます。

これは、クラスで以下のような関数を手動で作成する必要があることを意味しますか?

いいえ、同期はそれを行います。同期ブロックには一度に 1 つのスレッドしかアクセスできないため、最初のスレッドが同期ブロックを終了するまで、2 番目のスレッドはブロックされます。

于 2013-11-04T10:51:56.733 に答える