「ダブル・チェック・ロッキング」を編集中 (節単位)

== 主なプログラミング言語での実装例 ==
=== C# ===
[[C Sharp|C#]]における標準的なダブル・チェック・ロッキングの実装方法を示す。この記述方法では[[C Sharp|C#]]のキーワードのひとつであるvolatileを用いているのがミソである。なおvolatileキーワードと同等の機能を提供していない[[.NET Framework]]系の[[プログラミング言語]]も多く、それらでは別の実装方法を検討する必要がある。
<source lang="csharp">
public class MySingleton
{
    private static object _sync = new object();
    private static volatile MySingleton _instance = null;

    // プライベートコンストラクター
    // ※本クラスを除き、newキーワードによるインスタンス生成を出来なくする。
    private MySingleton()
    {
    }

    // 
    public static MySingleton GetInstance()
    {
        // 1回目の大雑把なチェック
        // ロックしていない「nullではない場合」の処理が高速化されます。
        if (null == _instance)
        {
            // ロック
            // ここで処理は急激に重くなります。
            lock (_sync)
            {
                // 2回目の厳密なチェック
                if (null == _instance)
                {
                    _instance = new MySingleton();
                }
            }
        }
        return _instance;
    }
}
</source>

=== C# (Lazy) ===
[[.NET Framework 4.0]]から標準でLazy<T>クラス（System名前空間）が用意されており、これを使うことで簡潔明瞭にダブル・チェック・ロッキングを記述できるようになった<!--<ref>{{cite 
 |title=C# 4.0 in a Nutshell
 |last=Albahari
 |first=Joseph 
 |isbn=0596800959
 |year=2010
 |publisher=O'Reilly Media
 |chapter=Threading in C#: Using Threads
 |chapterurl=http://www.albahari.com/threading/part3.aspx#_LazyT
 |quote=<code>Lazy&lt;T&gt;</code> actually implements […] double-checked locking. Double-checked locking performs an additional volatile read to avoid the cost of obtaining a lock if the object is already initialized.
}}</ref>-->。
この記述方法は[[C Sharp|C#]]に依存した機能も特に使われておらず、[[.NET Framework]]系の様々な[[プログラミング言語]]へも特に悩むことなく移植・実装可能であると思われる。
<source lang="csharp">
using System;

public class MySingleton
{
    private static readonly Lazy<MySingleton> _instance  
        = new Lazy<MySingleton>(() => new MySingleton());

    private MySingleton()
    {
    }

    public static MySingleton GetInstance()
    {
        return _instance.Value;
    }
}
</source>

=== Java ===
[[Java]]では[[仕様]]において[[アウトオブオーダー]]を用いるメモリモデルが可能となっていたため、この[[イディオム]]を使うことには問題があり、一部の[[実装]]では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。大雑把にいえばJavaでは「new（メモリ確保）」と「コンストラクタ実行」のタイミングが異なる。

よって、[[Java]]では絶対にダブルチェックロッキングを使用してはならない。

たとえば以下のような[[Java]]の[[ソースコード]]があったとする。
<source lang="java">
Person hage = new Person();
hage.say();
</source>
これが一部のJava実装では以下のような動作になる。
# １行目で[[メモリ]]が確保される。
#: いわゆるmallocが実行されhage[[変数]]自体は[[null]]ではなくなる。
#: ただし[[コンストラクタ]]はまだ実行されていない。
# 2行目のインスタンスを初めて使うときにコンストラクタが実行される。
#: [[コンストラクタ]]が実行されるタイミングは、オリジナル（newを実行した[[スレッド]]の持つ）インスタンスに対して外部から[[メンバー関数]]や[[メンバー変数]]に初回アクセスがあったときとなる。これを[[遅延初期化]]（lazy initialization）という。これによりhage[[変数]]自体は[[null]]ではないので後続スレッドはコンストラクタを実行していない不完全な[[インスタンス]]の[[参照]]を取得できてしまう。

[[Objective-C]]のallocとinitの動作に近いものが全自動で実行されてしまうような感じである。
<source lang="objc">
Parson* hage = [[Parson alloc] init];
</source>

<source lang="java">
public static Singleton getInstance()
{
    // 1: 先行スレッドから見た場合はnull
    //
    // 3: 後続スレッドから見た場合は非null、
    //    ただしコンストラクタが実行されていない不完全なものである場合がある。
    if (instance == null)
    {
        synchronized(Singleton.class)
        {
            if (instance == null)
            {
                // 2:
                // 先行スレッドによりメモリが割り当てられてnullではなくなるが、
                // この時点でコンストラクタは実行されていない。
                instance = new Singleton();
            }
        }
    }
    return instance;
}
</source>