無料学習の推奨事項: Java 基本チュートリアル
ロック ロックとプロデューサー/コンシューマーの問題
従来の同期ロック
基本的なチケット販売の例を実装します:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
ここではラムダ式が使用されていることに注意してください。ラムダ式の詳細な説明については、「Java の基礎 - ラムダ式」を参照してください
これは、同時実行性を実現するために従来の同期を使用することです。同期の本質はキューとロックです。カフェテリアに並ぶようなものです。行列がないと混乱してしまいます。一人へのサービスが完了して初めて、他の人もサービスを受けることができます。
Lock
前述したように、JVM は変数への同期アクセスを実現し、wait と notification を使用してスレッド間通信を実装するための synchronized キーワードを提供します。 jdk1.5以降、JAVAではsynchronizedと同様の機能を実装するためのLockクラスが提供され、またスレッド間の通信を表示するためのConditionも提供されています。
Lock クラスは Java クラスが提供する機能であり、豊富な API により Lock クラスの同期機能は同期よりも強力です。
java.util.Concurrent パッケージには、Condition と lock (標準ロック) の 3 つのインターフェイスがあります。 ReadWriteLock ロック (読み取り/書き込みロック)
Lock 実装は、同期されたメソッドやステートメントを使用して取得できるよりも広範囲のロック操作を提供します。これらにより、より柔軟な構造化が可能になり、完全に異なるプロパティを持つことができ、関連する複数のオブジェクト条件をサポートできます。
1 |
|
lock() はロック、unlock() はロック解除を意味します
JDK 公式ドキュメントで説明されています
すべて既知の実装クラス:
ReentrantLock リエントラント ロック
ReentrantReadWriteLock.ReadLock 読み取りロック
ReentrantReadWriteLock.writeLock 書き込みロック
まず、ReentrantLock 実装クラスについて説明します。 :
ReentrantLock の基礎となるソース コード コンストラクター
公平なロック: 非常に公平で、早い者勝ちです。しかし問題は、3s と 3h のプロセスが到着した場合、3h が最初に来て、その後 3s が 3h 待機することですが、これは実際には良くありません。
不公平なロック: 非常に不公平です。キューをジャンプできます (デフォルト)
これについては後で詳しく説明します。
使い方、使用前ロック、使用後のロック解除
//ロックロックトリロジー
//1.new ReentranLock() ;構築
//2.Lock.lock();Lock
//3.finally();Unlock
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Synchronized と lock lock の違い
1.synchronized は組み込みの Java キーワード、lock は Java クラスです
2.synchronized はロックの取得ステータスを判断できません、lock はロックが取得されたかどうかを判断できます
3.同期は自動的に行われます。ロックを解除するには (a-)、手動でロックを解除する必要があります。ロックが解放されない場合、デッドロックが発生します。
4. 同期スレッド 1 (ロックの取得、ブロック)、スレッド 2 (待機、愚かな待機)
lock.tryLock() はロックの取得を試みますが、常に起こるとは限りません。お待ちください
5. 同期された再入可能なロック、中断できない不公平なロック。ロック、リエントラントロック、ロックを判定可能、公平・不公平を自分で設定可能(自分で設定可能)
6. synchronized は少量のコード同期問題に適し、lock lock は大量のコード同期の問題に適しています。同期されたコードの量
同期されたロック オブジェクトと同期されたコード ブロック メソッド
従来のプロデューサーとコンシューマーの問題
従来のプロデューサーとコンシューマーは待機通知メソッドに基づいていますこれを実現するために、オブジェクト クラスのワードと同期キーが使用されます。
面接中に、プロデューサーとコンシューマーのコードを手書きすることは非常に一般的です。
面接筆記試験の古典的な質問:
シングルトン モードの並べ替えアルゴリズム プロデューサーとコンシューマーのデッドロック
プロデューサーとコンシューマーの問題の同期バージョン
スレッド間の通信の問題: プロデューサー ウェイク待ち-up with Consumer issues, notification wake-up
スレッドは同じ変数を操作するために A B を交互に実行します。number=0
A num 1
B num-1
注: はlocked メソッドでは、業務通知を判断して待つという実行の考え方です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
図に示すように、基本的に必要な機能は実現できますただし、問題は引き続き発生します。この時点で 2 つのスレッドを追加して再試行すると、
1 2 3 4 |
|
导致当前线程等待,直到另一个线程调用此对象的notify()方法或notifyAll()方法,或指定的时间已过。
线程也可以唤醒,而不会被通知,中断或超时,即所谓的虚假唤醒 。 虽然这在实践中很少会发生,但应用程序必须通过测试应该使线程被唤醒的条件来防范,并且如果条件不满足则继续等待。 换句话说,等待应该总是出现在循环中,就像这样:
1 2 3 4 5 |
|
注意点:防止虚假唤醒问题。
我们代码中用的是if判断,而应该用while判断
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Lock版的生产者和消费者问题
在synchronized版本中,我们使用了wait和notify来实现线程之间的同步
在lock中,
此时synchronized被lock替换了,那么wait和notify用什么来替换呢?
我们在官方文档java.util.concurrent.locks 中,找到Lock类,然后在底部找到了
Condition newCondition()
返回一个新Condition绑定到该实例Lock实例。
在等待条件之前,锁必须由当前线程保持。 呼叫Condition.await()将在等待之前将原子释放锁,并在等待返回之前重新获取锁。
然后我们再来了解Condition类
Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象,以便通过将这些对象与任意 Lock 实现组合使用,为每个对象提供多个等待 set(wait-set)。其中,Lock 替代了 synchronized 方法和语句的使用,Condition 替代了 Object 监视器方法的使用。
一个Condition实例本质上绑定到一个锁。 要获得特定Condition实例的Condition实例,请使用其newCondition()方法。
我们可以看到,使用的时候new一个Condition对象。然后用await替代wait,signal替换notify
代码实现
//判断等待+业务+通知
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
注意:主函数部分于最上面的代码一样。
这时候虽然说是正确的,但是它是一个随机分布的状态,现在我们希望它有序执行,即A执行完了执行B,B执行C,C完了执行D。即精准通知。
Condition实现精准通知唤醒
Condition实现精准的通知和唤醒
我们构造三个线程,要求A执行完了执行B,B执行完了执行C,C执行完了执行D.
代码思想:
//加多个监视器,通过监视器来判断唤醒的是哪一个人
//设置多个同步监视器,每个监视器监视一个线程
//实例:生产线,下单->支付->交易->物流
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 |
|
相关学习推荐:java基础
以上がJava ではロックとプロデューサー/コンシューマーの問題が発生しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。