シングルトンパターン - 初期バインディング（静的変数を含む）は、ミューテックスロックの必要性を減らしますか？

Question

早期のバインディングは、同期の問題を解決すると言います。私は "どのように"理解できませんでした。これはJavaにとって特別なものか、C++にも同じことが当てはまりますか？

この方法では、実際にはミューテックスロックは必要ありませんか？あなたはsingeltonメンバーは、あなたが作成のみを同期することができ 、最初の呼び出しまでヌル残ることをしたい場合には

Answer 1

私は、スレッドを開始/作成する前にSingletonインスタンスを作成することを指していると考えているため、作成時の同期の必要性が軽減されます。

EDIT：C++やC++で静的変数

をに関する情報を追加するデビッド・ハークネスのような実行は、Javaのために言及する前に、静的変数も初期化されます。 C++でのこの問題の1つは、システムが初期化されるまでmalloc/newへの呼び出しが実行されないような組み込み環境である可能性があります。この場合、シングルトン静的初期化子を使用すると問題が生じる可能性があります。

Answer 2

。 例えば

Answer 3

getInstance() { 
    if (singleton == null) { 
     lock(); 
     if (singleton == null) { 
       singleton = new Singleton(); 
     } 
     unlock(); 
    } 
    return singleton; 
} 

ためJVMは、各クラスが完全に他のスレッドを介してそれへのアクセスを許可する前にロードされることを保証します。つまり、上記のuniqueInstanceを含むすべての静的変数は、完全にインスタンス化されてからアクセスされます。これはJava固有のもので、インスタンスの公開を保護するための同期が必要ないことを意味します。

Answer 4

答えはYES!です。このメソッドを使用すると、 "get instance"のロックは必要ありません
--Edit--
オブジェクトの作成は、コードがロードされる前にロードされていることを保証するOSによって読み込みプロセスの一部ですランニング。
P.s.それはC++にも適用されます。
注：
1.「get instance」のロックは必要ありませんが、インスタンスの共有メンバーがある場合は必要になることがあります。
2.これは、インスタンスの初期化にパラメータを必要としない場合にのみ可能です。

Answer 5

怠惰なインスタンス化が解決しようとしたことの1つ（C++関連だけでなく）はstatic initialization order fiascoでした。これは初期化の順序を（複数の翻訳単位で）ほとんど制御できないという問題ですが、依存関係ではオブジェクトがすでに存在してから別のオブジェクトを作成する必要があります。遅延インスタンス化では、オブジェクトは必要に応じて作成されるため、循環依存がない限り、大丈夫です。

getInstance（）ごとにロックするコストを回避したい場合でも、Initialize（）関数を追加してスレッドを開始する前に、すべてのシングルトンを初期化しても、あなたのクラス。こうすることで、シングルトンは一度しか初期化されず、初期化された後にのみアクセスされるというアサーションでチェックできます。それらがアクセスされたとき

• 共有リソースがまだロックする必要があります。

  備考。

• （他のコンパイラについてはわからないgccを使用している場合）、最も簡単な解決策は、getInstanceで静的関数変数を使用し、その変数への参照を返すことです。これはスレッドセーフです。

  class Example 
  { 
      ... 
      static Example& getInstance() 
      { 
      static Example instance; 
      return instance; 
      } 
  };