ロックのパフォーマンス：ロックの長さとロックの比較多くの場合、

Question

クイック背景：私はアプリケーションの重要な部分を再設計しています。このアプリはデータベースからデータ/ DTOをキャッシュする大きなツリースタイルのデータ構造を持っています。大きなツリーの更新は、主に次の2つの方法で行われます。1.ユーザーがトリガーしたコマンド2.バックグラウンドで実行されたジョブからの自動更新。

いずれかの操作タイプ（ユーザ/自動）が発生すると、データ構造をロック（明示的にロック）しています。私は一貫性の問題に遭遇していたので、すべてをロックすると、キャッシュ内のデータの整合性を保護するのが最も理にかなったようでした。

質問：私は、任意のユーザードリブンの更新がトップにプッシュされ、最初に処理を受けるデータ構造、に命令を処理するために（多分JMS）キューのいくつかの種類を実装することを考えた後、多くの自動アップデートがで発生する可能性がありますので、 。自動 "タスク"のバルク/未知のサイズのセットを扱う場合、私はそれらを個別に実行してロックさせるか、時間をかけて一括してロックして一度ロックしようとするかを判断しようとしています。問題の真の要点は、更新するタスクのいずれかがツリー全体に影響する可能性があることです。

多くのトランザクションで大規模な更新が行われる可能性があります。大量の一括更新を試して結合し、1回だけロックするだけです。データの種類、更新の種類、頻度などが多分わかっています。「より頻繁にロックを小さくする」または「もっと長くする」という一般的なルールがあるかどうかはわかりませんでした。

Answer 1

答えは、プログラムがロックされていないデータ構造でかなりの時間を費やしているかどうかによって異なります。そうでない場合は、保留中のすべての更新に対して一度ロックすることをお勧めします。

理由は、ロックを待っている可能性のある他のスレッドが起動し、更新スレッドがすぐにリソースを再びロックすると、無駄にスリープ状態に戻ることがあるからです。または、更新は、キャッシュ利用に悪い可能性がある別のスレッドによって中断されます。また、アップデートに比べると小さなロックがかかります：パイプラインをフラッシュしなければならないかもしれない、メモリアクセスが自由に並べ替えられないなどの可能性があります。

スレッドは、他のスレッドがトランザクションを完了することができ、それによって競合が減少すると予想される場合は、更新ごとに再ロックを検討します。

ユーザーの更新とバックグラウンドの更新を想定しているように、さまざまな更新プログラムの優先順位が異なる場合は、優先度の低い更新プログラムのデータ構造をロックダウンすることをお勧めしますどのような方法でも、優先度の高いタスクの実行を防止します。

Answer 2

何らかのキューを実装すると、すべての並行性が失われます。一度に1000件のリクエストを受け取った場合、それがどれほど非効率であるか考えてみてください。

このコードでは、並行したツリーを調べてみてください。 https://github.com/npgall/concurrent-trees