AQSの重要性
最初に、AQS（AbstractQueuedSynchronizer）の重要性を紹介して、AQSがどのクラスで使用されているかを確認しましょう。
図に示すように、AQSはReentrantLock、ReentrantReadWriteLock、Semaphore、CountDownLatch、ThreadPoolExcutor（JDK 1.8）のワーカーで使用され、 AQSはこれらのクラスの基本原則です。
上記のクラスの多くは一般的に使用されるクラスであり、それらのほとんどは前のクラスで詳細に紹介されています。したがって、JUCパッケージの多くの重要なツールクラスはAQSフレームワークから切り離せないため、AQSの重要性は言うまでもありません。 。
AQSを学ぶという考え
次に、AQSを学ぶという考えについての私の理解を紹介したいと思います。AQSクラスの内部構造は、一般クラスよりもはるかに複雑です。詳細が多く、把握しにくいため、ソースコードを直接見てみると、わかりやすいです。自分自身を気絶させると、細部に陥りやすくなります。そして戻ってください。
我々は通常、我々が話すように、一般的に、自分でReentrantLockのようなツールを開発する必要はありませんので、実際には、私たちのプログラマのほとんどは、ビジネス開発者ではなく、JDKの開発者であり、直接開発にAQSを使用していません。 JDKがすでに提供しているため、以前のReentrantLockやSemaphoreなどのカプセル化されたスレッドコラボレーションツールクラスの多くはJDKによって提供され、AQSは内部で使用されます。これらのツールクラスは基本的に、ほとんどのビジネスシナリオをカバーするのに十分です。 AQSを理解していなくてもスムーズに開発できます。
AQSを学ぶ目的はコードを開発することではないのに、なぜAQSを学ぶ必要があるのでしょうか。私の意見では、AQSの研究の主な目的は、技術を向上させ、インタビューに回答するために、その背後にある原理を理解し、設計のアイデアを学ぶことです。したがって、主な目的は、AQSが必要な理由やAQSの役割を知るなど、マクロの観点からAQSを解釈することです。マクロの考え方を理解した後、その内部構造を分析し、より簡単に学習します。
ロックとコラボレーションには共通点があります。バルブ機能です。
AQS、以前のReentrantLockとSemaphoreを理解するための出発点として、おなじみのクラスを使用してください。2つの間に類似点はありますか？
実際、それらはすべてバルブとして使用できます。たとえば、セマフォのライセンス数を1に設定すると、ライセンスが1つしかないため、通過できるスレッドは1つだけになり、前のスレッドがライセンスを返すと、他のスレッドが引き続きライセンスを取得できるようになります。 。実際、これはReentrantLockと非常によく似ています。ロックを取得できるのは1つのスレッドのみであり、このスレッドがロックを解放すると、他のスレッドがロックを取得できるようになります。次に、スレッドが現在追加のライセンスがないことを検出した場合、またはロックが現在使用できない場合、スレッドはブロックされ、後続のライセンスまたはロックが解放された後にウェイクアップされるため、これらのリンクは比較的類似しています。
上記のReentrantLockとSemaphoreに加えて、CountDownLatch、ReentrantReadWriteLock、およびその他のツールクラスには、スレッドが「コラボレーション」できるようにする同様の関数があることがわかります。実際、これらはすべて、背後でAQSを使用して実装されています。
なぜAQSが必要なのですか
上記の予兆を踏まえて、今考えてみてください。なぜAQSが必要なのですか。
その理由は、上記のコラボレーションクラスには多くの同様の作業があるため、同様の作業を実装するコードを抽出して、それを新しい低レベルのツールクラス（またはフレームワークと呼ばれる）に変換できる場合は、これを使用できます。上位レベルのコードを構築するためのツールクラス。このツールクラスは実際にはAQSです。
AQSを使用すると、ReentrantLockやSemaphoreなどのスレッドコラボレーションツールクラスの場合、スレッドスケジューリングの詳細をそれほど気にする必要はなく、それぞれの設計ロジックを実装するだけで済みます。
AQSがない場合
次に、逆に考えてみます。AQSがない場合はどうなるでしょうか。
AQSがない場合、各スレッドコラボレーションツールクラスは、少なくとも以下を実装する必要があります。
- 状態の原子性管理
- スレッドのブロックとブロック解除
- キュー管理
ここでのステータスは、ツールクラスごとに異なる意味を持ちます。たとえば、ReentrantLockの場合、ロックが再入力される回数を維持する必要がありますが、再入国者の数を保存する変数は、同時に複数のスレッドによって操作されます。時間、スレッドセーフを確保するために処理する必要があります。それだけでなく、ロックを取得していないスレッドについては、適切なタイミングでブロック、キューイング、およびウェイクアップする必要があります。したがって、これらのコンテンツは実際にはより面倒で反復的であり、これらのタスクは現在AQSによって実行されています。
AQSがない場合、関連するロジックを自分で実装するにはReentrantLockなどのクラスが必要ですが、各スレッドコラボレーションツールクラスがこれらのコンテンツを正しく効率的に実装することは非常に困難です。AQSは、すべての「汚い仕事」を行うのに役立つため、ReentrantLockやSemaphoreなどのクラスの場合、独自のビジネスロジックに注意を払うだけで済みます。ことわざにあるように、「静かにする時間はありませんが、誰かがあなたのために体重を運んでいます」。
アナロジー：人事と面接官
これが表示された場合でも、AQSの役割を特に理解していない場合は、次の例えをご覧ください。AQSとスレッドコラボレーションツールを「擬人化」と比較し、HRやインタビュアーと比較します。
これは、学校の採用面接に参加する候補者のシーンをシミュレートします。企業の場合、面接には通常、面接官と人事部の参加が必要です。通常、面接にはグループフェイスとシングルフェイスの2種類があります。グループフェイスとは、複数の生徒が一緒に参加するインタビューのことです。たとえば、10人が一緒にインタビューすることが規定されています。グループフェイスのルールは次のとおりです。最初に10人を集め、次に制服インタビュー。
また、一方的な面接は、多くの場合、1対1で合理化されます。合計5人の面接官が一方的な面接を行っている、つまり、この5人の面接官が同時に候補者に面接しているとします。面接の過程で、候補者は列に並びます。前の候補者が面接を終えた後、後者は候補者がフォローします。面接を開始するための無料の面接官を見つけます。これは一方的なシナリオです。
一見したところ、グループ面接と片面面接のルールは大きく異なります。前者は複数の面接用であり、後者は1つずつの面接用です。しかし実際には、グループ側とシングル側には多くの類似点（またはプロセスまたはリンクと呼ばれる）があり、これらの類似点は人事部によって処理されることがよくあります。たとえば、面接官が来ると、HRは候補者がサインインし、座って待機し、キューに入れるように手配する必要があります。次に、HRは複数の候補者間の競合を避けるために番号に電話をかける必要があります。同時に、HRは次のことを確認する必要があります。最終的には待機中の学生全員が呼ばれます。このシリーズの内容は人事担当で、片面でもグループでも内容は同じです。面接でこれらのHRによって行われた作業は、実際にはAQSによって行われた作業と比較できます。
たとえば、具体的な面接のルールは、グループフェイスルールは5人ですか、それとも10人ですか。片面ですか、それともグループですか？これらはインタビュアーによって手配されます。面接官にとっては、候補者が番号の競合があるかどうか、待つ方法、電話をかける方法、休憩する場所があるかどうかなどは人事の責任の範囲であるため、彼は気にしません。
ここでのインタビュアーは、特定のコラボレーションロジックツールを実装するためのAQSの使用に対応しており、HRはAQSの略です。候補者を休ませると言ったのは、CPUを消費し続けないようにスレッドをブロックすることを意味します。その後、候補者が面接に行くように求めることは、スレッドをウェイクアップすることを意味します。
グループフェイスのプロセスはCountDownLatchに似ています。CountDownLatchは最初にカウントダウンする必要のある初期値を設定します。たとえば10です。候補者が来るたびにカウントが減らされます。10人全員がそこにいる場合は、面接が始まります。同様に、片側はセマフォセマフォとして理解できます.5つのライセンスがあると仮定すると、各スレッドは一度に1つのライセンスを取得します。これは、並行面接で5人の面接官がいるのと同様であり、候補者は面接許可の前に最初に取得する必要があります。 、面接後に許可証を返却してください。
CountDownLatchやSemaphoreなどのツールの場合、独自の「重要な」ルールを決定する必要があります。グループのように、面接の候補者を10人集めるのでしょうか。それとも、片側のように、1つ1つでしょうか。ルールが決定された後、インタビュアーへの挨拶（スレッドのスケジューリングと同様）などの残りの一連のタスクをAQSに引き渡すことができます。このように、それぞれの責任は非常に独立しており、明確です。
AQSの役割
さて、上記を理解した後、AQSの役割を要約しましょう。
AQSは、ロックやシンクロナイザーなどのスレッドコラボレーションツールを構築するためのフレームワークです。AQSを使用すると、スレッドコラボレーション用の多くのツールクラスを簡単に作成できます。AQSを使用すると、より高いレベルを作成できます。AQSの開発により、ワークロードが大幅に削減され、再作成が回避されます。また、AQSがこれらすべてのことを行っているため、上層による不適切な取り扱いによって引き起こされるスレッドセーフの問題を回避します。つまり、AQSを使用すると、スレッドコラボレーションツールの構築がはるかに簡単になります。
総括する
AQSのアイデア、AQSが必要な理由、AQSの役割を学び、AQSを使用するとスレッドコラボレーションツールを簡単に実装できます。AQSはJUCパッケージで広く使用されています。