問題タブ [double-checked-locking]

私のチームは現在この問題について議論しています。

問題のコードは、

私が見た投稿のいくつかは、これは大きなNO NOかもしれないと言っています（TryGetValueを使用している場合）。しかし、私たちのチームのメンバーは、「ContainsKey」はキーコレクションを反復処理せず、O（1）のハッシュコードを介してキーが含まれているかどうかをチェックするため、問題ないと述べています。したがって、彼らはここに危険はないと主張します。

この件に関して、正直なご意見をお聞かせください。

二重チェックのロックを使用するコードに出くわし続けていますが、なぜそれが使用されているのか、いまだに混乱しています。

私は最初、ダブルチェック ロックが壊れていることを知りませんでした。それを知ったとき、この疑問が拡大しました。そもそもなぜ人々はそれを使用するのでしょうか? コンペア＆スワップの方がいいんじゃない？

(上記のコードは C# 用ですが、私の質問は C# と Java の両方に当てはまります。)

二重チェックのロックには、アトミック操作と比較して、ある種の固有の利点がありますか?

最近、C＃コードの一部をリファクタリングしていて、いくつかのダブルチェックされたロック方法が実行されていることに気付きました。当時はそれが悪い習慣だとは知らなかったので、本当にそれを取り除きたいと思っています。

問題は、怠惰に初期化され、多くのスレッドによって頻繁にアクセスされる必要があるクラスがあることです。また、初期化されたオブジェクトがメモリ内に長く留まらないようにするために弱参照を使用することを計画しているため、初期化を静的初期化子に移動したくありません。ただし、必要に応じて、オブジェクトを「復活」させて、これがスレッドセーフな方法で行われるようにします。

C＃でReaderWriterLockSlimを使用し、最初のチェックの前にUpgradeableReadLockを入力してから、必要に応じて初期化用の書き込みロックを入力することが許容できる解決策になるかどうか疑問に思いました。これが私が念頭に置いていることです：

私のポイントは、他のスレッドがアイテムをもう一度初期化しようとするべきではないということですが、値が初期化されると、多くのスレッドが同時に読み取る必要があります。アップグレード可能な読み取りロックは、書き込みロックが取得された場合にすべてのリーダーをブロックする必要があるため、オブジェクトの初期化中の動作は、アップグレード可能な読み取りロックが開始されるロックステートメントの場合と同様になります。初期化後、アップグレード可能な読み取りロックは複数のスレッドを許可するため、各スレッドを待機することによるパフォーマンスへの影響はありません。

また、ここでvolatileを使用すると、読み取り前と書き込み後にメモリバリアが自動的に挿入されるという記事を読みました。したがって、_valueReferenceオブジェクトが正しく読み取られるようにするには、読み取りと書き込みの間に手動で定義されたバリアが1つだけあれば十分だと思います。このアプローチを使用することについてのあなたのアドバイスと批判に喜んで感謝します。

私はLazyReferenceクラスを数年間使用しています（もちろん定期的にではありませんが、非常に役立つ場合もあります）。クラスはここで見ることができます。クレジットは、Robbie Vanbrabant (クラス作成者) と Joshua Bloch の著名な「Effective Java 2nd edt」に贈られます。(元のコード)。

クラスは (Java 5+ で) 正しく動作しますが、潜在的な問題が 1 つあります。instanceProvider返された場合(Guiceの契約nullに従ってはいけませんが…)、メソッドを実行するたびに LOCK が保持され、何度も呼び出されます。契約を破った人には良い罰のように見えますが (he-he)、値を設定する可能性のあるフィールドを遅延して初期化する必要がある場合はどうすればよいでしょうか?Provider.get()LazyReference.get()instanceProvider.getnull

LazyReference を少し変更しました。

私見は問題なく動作するはずです（別の意見がある場合は、コメントや批判を投稿してください）。しかし、ブール値volatileから修飾子を削除するとどうなるでしょうか(もちろんそのままにしておきます)。それでも正しく動作しますか?isNullinstance

に格納されている共有リソースを初期化するためにI/Oバウンド操作を実行する必要がある複数のスレッドで実行できるコードがありますConcurrentMap。このコードスレッドを安全にし、共有リソースを初期化するための不要な呼び出しを回避する必要があります。バグのあるコードは次のとおりです。

上記のコードを使用すると、複数のスレッドがをチェックしてリソースが存在しないことを確認し、すべてが高額なConcurrentMap呼び出しを試みる可能性があります。getResource()共有リソースの単一の初期化のみを保証し、リソースが初期化された後にコードを効率的にするために、私は次のようなことをしたいと思います。

これはダブルチェックロックの安全なバージョンですか？チェックが呼び出されるので、チェックConcurrentMapは宣言された共有リソースのように動作し、volatile発生する可能性のある「部分的な初期化」の問題を防ぐように思われます。

同じ秒で複数の Web 要求を介して呼び出すことができる次のコードがあります。そのため、2 番目以降のリクエストがデータベースにヒットするのは望ましくありませんが、最初のリクエストがヒットするまで待ちます。

Lazy<T> 代わりにキーワードクラスを使用するようにこれをリファクタリングする必要がありますか? 1 つのコードに対して 10 回の呼び出しがLazy<T>同時に発生した場合、それらの呼び出しのうち 9 回は最初の呼び出しが完了するまで待機しますか?

Head Firstデザイン パターン ブックから、ダブル チェック ロックを使用したシングルトン パターンが以下のように実装されました。

が使われている理由がわかりませんvolatile。volatile使用法は二重チェック ロックを使用する目的、つまりパフォーマンスを無効にしません か?

それは私が持っているものです：

• Windowsサービス
  • C＃
  • マルチスレッド
  • サービスはRead-Write-Lockを使用します（一度に複数の読み取り、書き込みは他の読み取り/書き込みスレッドをブロックします）
• シンプルな自作のDB
  • C ++
  • メモリに収まるほど小さい
  • 起動時にロードしたくない十分な大きさ（例：10GB）
  • 読み取りパフォーマンスは非常に重要です
  • 書くことはそれほど重要ではありません
  • 木の構造
  • ツリーノードに保持されている情報はファイルに保存されます
  • パフォーマンスを向上させるために、ファイルは最初に使用およびキャッシュされたときにのみロードされます
  • DBの起動を高速化するための遅延初期化

DBはこれらのノード情報に非常に頻繁に（1秒間に数千回の大きさで）アクセスし、私はあまり頻繁に書き込まないので、ある種のダブルチェックロックパターンを使用したいと思います。

ここでダブルチェックロックパターンについて多くの質問があることは知っていますが、非常に多くの異なる意見があるように思われるので、私の場合に何が最善かわかりません。私のセットアップで何をしますか？

次に例を示します。

• 100万ノードのツリー
• すべてのノードは、キーと値のペアのリストを格納します（永続性のためにファイルに格納され、ファイルサイズの大きさ：10kB）
• 初めてノードにアクセスするとき、リストはマップにロードおよび保存されます（sth。like std :: map）
• 次にこのノードにアクセスするときに、ファイルを再度ロードする必要はありません。マップから取得するだけです。
• 唯一の問題：2つのスレッドが初めてノードに同時にアクセスしていて、キャッシュマップに書き込みたい。これが発生する可能性は非常に低いですが、不可能ではありません。ここでスレッドセーフが必要になりますが、通常は必要ないので（特に、DB全体がメモリに格納されたら）、それほど時間はかかりません。

「ダブルチェックロック」のケースに遭遇している可能性があると思われるアプリのコードを見ています。私たちが行っているのと同様のサンプルコードをいくつか作成しました。

誰かがこれがダブルチェックロックをどのように経験しているのかを見ることができますか？それともこれは安全ですか？

wikiから借用したベースコード。

ダブルチェックロックについて質問があります。この例を考えてみましょう。

私が理解したように、上記のコードはシングルトンクラスを作成する正しい方法です。

ただし、NetBeansは外部のifステートメントを削除するように要求しているため、次のようになります。

これら2つのスニペットの唯一の違いは、2番目の例では、コードは常に同期ブロックに入り、最初の例では入りません。NetBeansをリッスンし、外部のifステートメントを削除するのはなぜですか？ロックを回避する方がよいはずです。