楽観と悲観的ロックデータは、同時実行のシナリオにおける競争の問題を解決するために使用されているが、それは2つの完全に異なる考え方です。これらの使用は、プログラミング言語やデータベースに限定されるものではなく、非常に広範です。
楽観的ロックの概念
データは、他の人が同時にデータを変更しないことを楽観非常に楽観的な操作を参照する、いわゆる楽観的ロックは、楽観的ロックはロックされていない、その間に他の人かどうかを判断するために修正するアップデートを実行する場合にのみ、他のものはあきらめる場合、データは、データは、他の操作を実行する、修正されます。
ペシミスティック・ロックのコンセプト
いわゆる悲観的ロック、データは悲観的に他の人が同時にデータを変更すると思い、比較的に悲観的であるとき、運転データで悲観的ロックはロックに直接データであり、ロックでは、操作が完了した後まで解放されます操作を参照他の人が運転データ中にロックすることができません。
オプティミスティック・ロックの実装
楽観的ロックの実装は、主CAS機構（比較および交換、比較、およびスワップ）の2種類があり、一つは機構のバージョン番号です。
CASメカニズム
CAS動作は、書き込むべき読み出すべき3つのオペランド、即ちメモリ位置（V）、期待値（A）と新たな値（B）が意図さを比較し、論理演算が含まれている場合、メモリ位置Vの値期待値Aに等しい、この位置は、新しい値Bに更新される、または動作しません。操作が成功するまで加えて、多くの操作は、操作が成功しなかった場合、つまり、CASスピンしている、再試行されていたであろう。
機構のバージョン番号
バージョン番号のメカニズムの基本的な考え方は、バージョンフィールドは、データのバージョン番号を示すために使用されるデータで増加する、各時刻データが変更されたバージョン番号が1だけ増加されます。場合は、クエリデータは、スレッド内のデータを更新する必要の後、一緒にデータのバージョン番号を読み込み、スレッド、それはバージョン番号が現在のバージョン番号と比較される前に読み取られるとき、一貫性のある場合は、操作が行われ、そうでない場合、その後、運転中止されます。
ペシミスティック・ロックの実装
ロックされているペシミスティック・ロックの実装では、データベースレベルで（例えば、Javaのsynchronizedキーワードなど）のコードレベルで、することができます（たとえば、MySQLの、排他ロックなど）のいずれかにロック。
楽観と悲観的ロックロックの長所と短所と利用シナリオ
楽観と悲観的ロックとは良いか悪いかは、彼らは自分の適切なシーンを持っていません。
機能的な制限
悲観的楽観的ロックロックと比べて、該当シーンは、バージョン番号CAS機構または機構であるか否かを、より制限されてきました。
別の例として、機構のバージョン番号場合、例えば、機構は、それが複数の変数になると、CAS機構は無力であり、それはコードロック処理のブロック全体に同期させることができ、原子CAS単一可変動作を保証することができ表1のクエリデータは、時間のためですが、データは表2に更新されたときに、簡単なバージョン番号で楽観的ロックを達成することは困難です。
競争のレベル
以下競争シナリオ、楽観的ロックの利点（並行処理の競合が比較的小さい確率を生じます）。悲観的ロックは、コード・ブロックやデータをロックするので、他のスレッドが同時にアクセスすることはできません、我々は、応答の同時のスピードに影響する操作を入力するスレッドのリリースのロックを待つ必要があります。また、ロックと解除するロックは、追加のシステムリソースを消費する必要があり、それはまた、処理速度の同時影響を及ぼします。
熾烈な競争の中でシナリオ、悲観的ロック利点（並行処理の競合が高い確率を表示されます）。データが変更され、失敗を繰り返し更新することができるので、アップデートを実行し、CPUリソースの無駄が生じ、再試行し続けるために楽観的ロックので。
楽観的ロックはロックされているかどうか
データのAtomicIntegerは一例であるなど他のスレッドにより更新されるかどうかを判断するように更新する場合にのみ楽観的ロック自体は、ロックされていません。操作は排他ロックを追加するときしかし、時には楽観的ロックは、更新されたデータの実装ではMySQLのようなロック操作、と協働することができます。したがって、楽観的ロック自体として理解されるべき更新データのみをロックすることができる場合にのみ、ロックされていません。
CASの欠点
CASの主な欠点は、ABAの問題、高い競争と限られた機能自体のコストの問題を抱えています。
ABAの問題
データを操作するとき、いわゆるABAの問題は、そこに動作データの系列を実行するために別のスレッドがあるが、データが変更されたときにスレッド内のデータを再読み取り及びスレッドこと、スレッドを指し同じデータを読み始め、スレッドは、CAS操作は成功であると判断され、データが変更されたことを知ることができません。
いくつかのシーンでのABAの問題は、任意の害を引き起こすことはできませんが、いくつかのシナリオでは、問題が発生する場合があります。CASは、2つ（またはそれ以上）の後にも、データ、スタックデータを操作するように、元の値の復元後の変更、スタックの最上位であるが、それはスタックが変更された可能性があり、スタックのデータを変更するいくつかの原因となります問題。
ABAの問題のために、より効果的なプログラムは、バージョン番号の導入です。長いメモリ変化の値と同様に、バージョン番号の両方が変更されていない場合にのみ、動作中CAS専用メモリの値を比較していない場合、増分だけでなく、バージョン番号を比較し、CAS動作が正常に実行します。AtomicStampedReferenceバージョン番号で適用されているJavaクラスは、ABAの問題を解決します。
高い競争のオーバーヘッドの問題
同時競合の確率はCAS操作が失敗した場合、大きな競争力の高いシナリオで、大規模なCPUのオーバーヘッドの問題を引き起こし、再試行されていたであろう。この問題に対処するために、シンプルなアイデアが終了メカニズムの導入で再試行の回数が一定のしきい値を超えた場合、それが強制終了することができませんでした。もちろん、それは非常に競争力のあるシナリオで楽観的ロックの使用を避けることをお勧めします。
彼らの機能制限
CASは、CASとしてその単一の変数（または単一のメモリ値）アトミック動作を保証するために、比較的制限されています。それは複数の変数（または複数のメモリ値）になると、原子は必ずしもスレッドの安全性を保証するものではありませんので、この手段は、CASはそれを助けることはできません。また、CAS実装は、使用原子パケットにのみアトミッククラスによって、Javaの一般のユーザーがハードウェアサポートレベルプロセッサが直接使用することができない限られた柔軟性を必要とします。
「新しい友人が古い気性を知っていない、古い友人が新しい生活を知りませんでした。」