問題タブ [double-checked-locking]

私は次のようなクラスを持っています:

ここでは、クラスのインスタンスを作成し、プロパティで同期しclassます。

私のプロジェクトにはそのようなクラスがたくさんあります。メソッドを実装する基本クラスを作成するgetInstance方法があるので、すべてのクラスでこのコードを保持する必要はありませんか? ジェネリックを使用してみましたが、うまくいきませんでした。多分私が達成しようとしていることの例がありますか？

遅延初期化と、作成がスレッドセーフである必要のないオブジェクトの格納用に設計されたクラスがあります。コードは次のとおりです。

ここで、final変数tmpRefは、作成されたオブジェクトを格納してから、チェックされた変数に割り当てるために使用されますobject。これはテストでは機能しますが、確実に正しいとは言えず、コンパイラによって最適化されません。このアプローチを使用できますか、またはobjectフィールドを次のように宣言する必要がありますvolatileか?

また、ラッパー クラスを使用したバリアントは、行が

これに置き換える必要があります：

ラッパー クラスは次のようになります。

この例のいくつかは、マルチスレッド環境で安全に使用できますか (特に final ローカル フィールドを持つバリアント)?

並行性に戻ります。double checked lockingが機能するには、変数を として宣言する必要があることは明らかですvolatile。しかし、以下のようにダブルチェックロックを使用するとどうなるでしょうか。

通常のHashMapではなく、実際にConcurrentHashMapである必要があるのはなぜですか? すべてのマップの変更はブロック内で行われ、コードは反復子を使用しないため、技術的には「同時変更」の問題はありません。synchronized

API の使用ではなく概念について質問しているため、 putIfAbsent/の使用を提案しないでください:) この API の使用がvsの主題に寄与しない限り。computeIfAbsentHashMapConcurrentHashMap

2016-12-30 更新

この質問は、以下の Holger によるコメントによって回答されました。「HashMap.get構造は変更されませんが、あなたの の呼び出しは変更されます。同期ブロックの外側で のput呼び出しがあるため、操作の不完全な状態が同時に発生していることがわかります。」ありがとう！getput

私が提起した以前の質問に関して、

}

2 番目のインスタンスの null チェック条件を使用する必要があるのはなぜですか。それはどのような影響を与える可能性がありますか？

例を考えてみましょう:

この場合、揮発性は必要ですか?

以下の A fix that doesn't work のコード スニペットを理解できませんでした。（同じページに続く説明を読みました）。

2 つの同期ブロックがある場合、この DCL バージョンはどのように壊れていますか? または、Java5以降は適用されませんか?