JavaマルチスレッドでLockを使用する方法

Jdk1.5 以降では、java.util.concurrent.locks パッケージの下に、スレッド同期を実装する一連のインターフェイスとクラスがあります。スレッド同期に関して言えば、誰もが synchronized キーワードを思い浮かべるかもしれません

これは Java の組み込みキーワードであり、スレッドの同期を処理するために使用されます。ただし、このキーワードには多くの欠陥があり、あまり便利ではなく直感的に使用できないため、Lock が表示されます。以下、

説明ロックを比較します。

通常、synchronized キーワードを使用すると、次の問題が発生します。

(1) 制御不能、ロックを自由にロックしたり解放したりできない。

(2) 効率は比較的低いです。たとえば、現在 2 つのファイルを同時に読み取っています。読み込みと読み込みは相互に影響しません。ただし、読み込みオブジェクトに synchronized を使用して同期を実現すると、 ,

したがって、1 つのスレッドが入力される限り、他のスレッドは待機する必要があります。

(3) スレッドがロックを取得したかどうかを知る方法はありません。

Lock は上記の同期の問題をうまく解決できます。jdk1.5 以降では、読み取り/書き込みロックなどのさまざまなロックも提供されていますが、synchronized

public interface Lock { 　　// 用来获取锁，如果锁已经被其他线程获取，则一直等待，直到获取到锁 void lock(); 　　// 该方法获取锁时，可以响应中断，比如现在有两个线程，一个已经获取到了锁，另一个线程调用这个方法正在等待锁，但是此刻又不想让这个线程一直在这死等，可以通过 　　　　调用线程的Thread.interrupted()方法，来中断线程的等待过程 　　void lockInterruptibly() throws InterruptedException; 　　// tryLock方法会返回bool值，该方法会尝试着获取锁，如果获取到锁，就返回true，如果没有获取到锁，就返回false，但是该方法会立刻返回，而不会一直等待 boolean tryLock(); 　　// 这个方法和上面的tryLock差不多是一样的，只是会尝试指定的时间，如果在指定的时间内拿到了锁，则会返回true，如果在指定的时间内没有拿到锁，则会返回false boolean tryLock(long time, TimeUnit unit) throws InterruptedException; 　　// 释放锁 void unlock(); 　　// 实现线程通信，相当于wait和notify，后面会单独讲解 Condition newCondition(); }

Lock l = ...; l.lock(); try { 　　// access the resource protected by this lock } finally {// 必须使用try，最后在finally里面释放锁 　　l.unlock(); }

1 、関数

2. Source

lock は JUC パッケージで提供されるインターフェイスです。このインターフェイスには、最も一般的に使用される ReentrantLock (リエントラント ロック) を含む多くの実装クラスがあります。

3. ロックの強度

メソッド レベルで synchronized キーワードを変更します。はコードブロック上に装飾されています。

ロック オブジェクトは通常のインスタンス オブジェクトであり、このロックの範囲はこのインスタンスのライフ サイクルによって異なります。
ロックの強度は、lock() と lock() の 2 つのメソッドによって決まります。 2 つのメソッド間のコードはスレッドセーフであることが保証されています。ロックの範囲は、ロック インスタンスのライフサイクルによって異なります。

4. 柔軟性

lock は、いつロックするか、ロックを解放するかを個別に決定できます。 lock の lock() メソッドと lock() メソッドを呼び出すだけです。

5. 公平なロックと不公平なロック

利点: すべてのスレッドがリソースを取得でき、餓死することはありません。欠点: スループットが低く、キュー内の最初のスレッドを除いて他のスレッドがブロックされ、ブロックされたスレッドをウェイクアップする際の CPU オーバーヘッドが高くなります。

欠点: キューの途中にあるスレッドはロックを取得できないか、長時間ロックを取得できない可能性があり、最終的には餓死する可能性があります。
lock は、公平なロックと不公平なロック (デフォルトの不公平なロック) の 2 つのメカニズムを提供します。

6. 例外によりロックを解放するかどうか

ロック ロックで例外が発生した場合、占有されていたロックは積極的に解放されません。ロックは、unlock() を使用して手動で解放する必要があるため、通常は同期コード ブロックを try-catch に入れて、unlock を書き込みます() デッドロックを回避するメソッド。

7. ロックを取得できるかどうかを確認します。

lock は、ノンブロッキング競合ロック メソッド trylock() を提供し、戻り値はブール型です。これは、ロックの取得を試行するために使用されることを示します。取得が成功した場合は true を返し、取得が失敗した場合は false を返します。このメソッドは、何があってもすぐに戻ります。

8. スケジュールメソッド

9. 中断できるかどうか

synchronized はロックが解放されるのを待つことしかできず、割り込みには応答できません。

interrupt() を使用すると、ロックの待機中に割り込むことができます。

10. パフォーマンス

競争が激しくない場合、パフォーマンスはほぼ同じですが、競争が激しい場合、ロックのパフォーマンスが向上します。

Lock ロックでは、readwritelock を使用して読み取りと書き込みを分離することもできるため、マルチスレッド読み取り操作の効率が向上します。

11. 同期ロックのアップグレード

同期コード ブロックは、monitorenter/monitorexit 命令のペアによって実装されます。 Monitor の実装はオペレーティング システム内のミューテックス ロックに完全に依存しており、ユーザー モードからカーネル モードへの切り替えが必要なため、同期操作は未分化の重量級操作となります。

したがって、JVM は 3 つの異なるロック (バイアス ロック、軽量ロック、重量ロック) を提供するようになりました。

バイアス ロック:
競合が発生しない場合、デフォルトでバイアス ロックが使用されます。スレッドは、CAS 操作を使用してオブジェクト ヘッダーにスレッド ID を設定し、オブジェクトが現在のスレッドに偏っていることを示します。

目的: 多くのアプリケーション シナリオでは、ほとんどのオブジェクトのライフ サイクルは最大 1 つのスレッドによってロックされます。バイアスされたロックを使用すると、競合がない場合にオーバーヘッドを削減できます。

軽量ロック:
JVM は、現在のスレッドのスレッド ID と Java オブジェクト ヘッダーのスレッド ID を比較して、一貫性があるかどうかを確認します。一貫性がない場合 (たとえば、スレッド 2 がロック オブジェクト) の場合は、Java オブジェクト ヘッダーのレコードをチェックする必要があります。スレッド 1 が生きているかどうか (バイアスされたロックは積極的に解放されないため、スレッド 1 の格納されたスレッド ID のままです)。生きていない場合は、スレッド 1 が生きているかどうかを確認します。の場合、ロック オブジェクトはまだバイアスされたロックです (オブジェクト ヘッダーの threadID はスレッド 2 です)。存続する場合は、バイアス ロックを取り消し、軽量ロックにアップグレードします。

他のスレッドが軽量ロックを使用してリソースにアクセスする必要がある場合、スピン ロックの最適化を使用してリソースにアクセスします。

目的: ロック オブジェクトをめぐって競合するスレッドは多くなく、スレッドは長時間ロックを保持しません。スレッドをブロックすると、CPU がユーザー モードからカーネル モードに移行する必要があり、コストがかかります。ブロックした直後にロックが解放された場合、利益は損失に見合っていません。したがって、現時点ではスレッドをブロックしない方がよいでしょう。回転させてロックが解除されるのを待ちます。

ヘビーウェイト ロック:
スピンが失敗すると、自己選択が再度失敗する可能性が高いため、スレッドをブロックして CPU 消費量を削減するために、ヘビーウェイト ロックに直接アップグレードされます。

ロックがヘビーウェイト ロックにアップグレードされると、ロックを取得していないスレッドはブロックされ、ブロッキング キューに入ります。

以上がJavaマルチスレッドでLockを使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。