Java インタビュー - 楽観的ロックと悲観的ロック

インタビューの質問:

楽観的ロックと悲観的ロックの違い

(学習ビデオ共有: Java 教育ビデオ )

1. Optimistic Lock

私は常に同時実行性の問題はないと考えていますが、データをフェッチするたびに、他のスレッドはデータを変更しないだろうと常に考えています。ロックはされませんが、更新時に他のスレッドが以前にデータを変更したかどうかが判断されます。通常、バージョン番号メカニズムまたは CAS 操作を使用して

version メソッドを実装します:

通常、データ テーブルに追加されます。データ バージョン番号 version フィールドは、データが変更された回数を示します。データが変更されると、バージョン値は 1 ずつ増加します。スレッド A がデータ値を更新する場合、データの読み取り中にバージョン値も読み取ります。更新を送信するときは、読み取ったバージョン値が現在のデータベースのバージョン値と等しい場合にのみ更新し、それ以外の場合は再試行します。 . アップデートが成功するまでアップデート操作を行います。

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

(推奨される関連するインタビューの質問: Java インタビューの質問と回答)

CAS 操作方法:

つまり、比較と交換、または比較とset、データが配置されているメモリ値、期待値、および新しい値の 3 つのオペランドが関係します。更新が必要な場合は、現在のメモリ値が以前に取得した値と等しいかどうかを判断し、等しい場合は新しい値で更新し、失敗した場合は再試行します。一般的にはスピン操作ですが、つまり、継続的な再試行です。

2. 悲観的ロック

常に最悪のシナリオを想定してください。データをフェッチするたびに、他のスレッドがデータを変更すると考えて、データをロックします (読み取りロック、書き込みロック、行ロックなど)、他のスレッドがデータにアクセスする場合は、ブロックして中断する必要があります。行ロック、読み取りロック、書き込みロックなど、操作前にすべてロックされるデータベースに依存して実装できます。Java では、同期の概念も悲観的ロックです。

3. 適用可能なシナリオ

悲観的ロック: 書き込み操作が頻繁に行われるシナリオに適しており、読み取り操作が多数ある場合、読み取りのたびにロックが実行されます。これにより、大量のロック オーバーヘッドが追加され、システムのスループットが低下します。

オプティミスティック ロック: 読み取り操作がより頻繁に行われるシナリオに適しています。大量の書き込み操作が発生すると、データの競合が発生する可能性が高くなります。データの一貫性を確保するために、アプリケーション層は継続的にデータを再取得する必要があります。データを再取得すると、クエリ操作の数が増加し、システムのスループットが低下します。

要約: どちらにも独自の長所と短所があり、楽観的ロックは頻繁な読み取りに使用され、悲観的ロックは頻繁な書き込みに使用されます。

関連する推奨事項: Java 入門チュートリアル

以上がJava インタビュー - 楽観的ロックと悲観的ロックの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。