本チェックパターンは、本のExecument Javaの第48条に記載されており、このパターンは通常Javaでは適用できないことが指摘されています。このパターンの構造は次のとおりです。
public resource getResource（）{if（resource == null）{synchronized（this）{if（resource == null）{resource = new resource（）; }}} returnリソース; }このパターンは、次のコードの改善です。
public同期リソースgetResource（）{if（resource == null）{resource = new Resource（）; } Return Resource; }このコードの目的は、リソースの初期化を遅らせることです。しかし、アクセスするたびに、同期する必要があります。同期のオーバーヘッドを減らすために、ダブルチェックモードが利用可能です。
Javaでダブルチェックモードが無効である理由は、同期がない場合は参照タイプがスレッドセーフではないためです。ロングとダブル、ダブル、ダブルチェックモードを除く基本タイプの場合は、適用されます。たとえば、次のコードは正しいです。
プライベートインクカウント; public int getCount（）{if（count == 0）{synchronized（this）{if（count == 0）{count = computeCount（）; //時間のかかる計算}}} return count; }上記は、Javaのダブルチェックイディオムに関する一般的な結論です。しかし、Javaの記憶パターンも改善されているため、物事はまだ終わっていません。 Doug Leaは彼の記事に次のように書いています。「最新のJSR133 Javaメモリモデルによると、参照タイプが揮発性と宣言されている場合、ダブルチェックモードは機能します。」したがって、将来的には、Javaでダブルチェックモードを使用する必要があります。次のコードを使用できます。
民間の揮発性リソースリソース。 public resource getResource（）{if（resource == null）{synchronized（this）{if（resource == null）{resource = new resource（）; }}} returnリソース; }もちろん、JSR133仕様に続くのはJavaでなければなりません。
したがって、マルチスレッドまたはJVMでチューニングする際のオーダーアウトオブオーダーの書き込みのため、J2SE 1.4以前のバージョン以前のバージョンでは、ダブルチェックは使用できません。この問題はJ2SE 5.0で修正されており、揮発性キーワードを使用して、マルチスレッドの下でシングルトンを確保することができます。
パブリッククラスシングルトン{プライベートボラティールシングルトンインスタンス= null; public Singleton getInstance（）{if（instance == null）{synchronized（this）{if（instance == null）{instance = new Singleton（）; }} return instance; }}推奨される方法は、初期化オンデマンドホルダー（IODH）です。
パブリッククラスSingleton {Static Class SingletonHolder {Static Singleton Instance = new Singleton（）; } public static singleton getInstance（）{return singletonholder.instance; }}上記はこの記事に関するものです。誰もがJavaプログラミングを学ぶことが役立つことを願っています。