ダブル・チェック・ロッキング

提供: MonoBook
移動: 案内検索

ダブル・チェック・ロッキング英語:double check locking)とは、マルチスレッド環境下における変数に対して、初回はロックせず状態チェックを行い、そこで必要であれば再度ロックを掛けた後に状態チェックを行うというソフトウェア最適化技法、デザインパターンのひとつである。

概要[編集]

ダブル・チェック・ロッキングは、主にマルチスレッド環境下でのシングルトンパターンを実装する際にオーバーヘッドの低減を目的として使われることが多い。

マルチスレッド下における変数ロックは非常にオーバーヘッドが大きくスレッド数に比例して重くなる。ダブル・チェック・ロッキングはそのような状況下でロックの発生回数を可能な限り減らすことでプログラムの高速化を実現しようというものである。なお、シビアな速度を要求されないのであればソースコードとしては何も考えず常にロックした方が簡潔明瞭ではある。

主なプログラミング言語での実装例[編集]

C#[編集]

C#における標準的なダブル・チェック・ロッキングの実装方法を示す。この記述方法ではC#のキーワードのひとつであるvolatileを用いているのがミソである。なおvolatileキーワードと同等の機能を提供していない.NET Framework系のプログラミング言語も多く、それらでは別の実装方法を検討する必要がある。

public class MySingleton
{
    private static object _sync = new object();
    private static volatile MySingleton _instance = null;
 
    // プライベートコンストラクター
    // ※本クラスを除き、newキーワードによるインスタンス生成を出来なくする。
    private MySingleton()
    {
    }
 
    // 
    public static MySingleton GetInstance()
    {
        // 1回目のチェック
        // ロックしていないので高速に処理される
        if (null == _instance)
        {
            // ロック
            // ※このブロック内はクソ重い
            lock (_sync)
            {
                // 2回目のチェック
                if (null == _instance)
                {
                    _instance = new MySingleton();
                }
            }
        }
        return _instance;
    }
}

C# (Lazy)[編集]

.NET Framework 4.0から標準でLazy<T>クラス(System名前空間)が用意されており、これを使うことで簡潔明瞭にダブル・チェック・ロッキングを記述できるようになった。 この記述方法はC#に依存した機能も特に使われておらず、.NET Framework系の様々なプログラミング言語へも特に悩むことなく移植・実装可能であると思われる。

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;
    }
}

Java[編集]

Javaでは仕様においてアウトオブオーダーを用いるメモリモデルが可能となっていたため、このイディオムを使うことには問題があり、一部の実装では実際に正しく働かない可能性があることが知られている。詳細は http://www.ibm.com/developerworks/jp/java/library/j-dcl/ を参照。

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

たとえば以下のようなJavaソースコードがあったとする。

Person hage = new Person();
hage.say();

これが一部のJava実装では以下のような動作になる。

  1. 1行目でメモリが確保される。
    いわゆるmallocが実行されhage変数自体はnullではなくなる。
    ただしコンストラクタはまだ実行されない。
  2. 2行目の初めて使うときにコンストラクタが実行される。
    コンストラクタが実行されるタイミングは、オリジナル(newを実行したスレッドの持つ)インスタンスに対して外部からメンバー関数メンバー変数に初回アクセスがあったときとなる。これを遅延初期化(lazy initialization)という。これによりhage変数自体はnullではないので後続スレッドはコンストラクタを実行していない不完全なインスタンス参照を取得できてしまう。

Objective-Cのallocとinitの動作に近いものが全自動で実行されてしまうような感じである。

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

関連項目[編集]

参考文献[編集]