C#でマルチスレッドプログラミングを行う際、複数のスレッドから同じ変数にアクセスするコードを記述することは珍しくありません。

しかし、単純に共有変数へアクセスするだけでは、コンパイラやCPUによる最適化の影響で、スレッド間での値の同期が正しく行われないという問題が発生することがあります。

このような「メモリの可視性」に関する問題を解決するための手段の一つが volatileキーワード です。

volatileは、フィールドが複数のスレッドによって同時に変更される可能性があることをコンパイラに通知し、最適化による値のキャッシュや命令の並べ替えを抑制する役割 を持っています。

しかし、volatileは万能な同期機構ではなく、正しく理解して使用しなければ、予期せぬバグを引き起こす原因にもなり得ます。

本記事では、volatileの動作原理から正しい使い方、そして他の同期手法との違いについて詳しく解説します。

目次 [ close ]
  1. volatileキーワードとは
  2. なぜvolatileが必要なのか：コンパイラ最適化とCPUキャッシュ
    1. コンパイラによる最適化の例
    2. CPUキャッシュとメモリモデル
  3. volatileの使い方と使用可能な型
    1. volatileを使用できる型
  4. volatileとアトミック操作の誤解
    1. 複合操作の危険性
  5. lockやInterlockedとの使い分け
    1. volatileを選ぶべきケース
    2. lockを選ぶべきケース
  6. 実践的なコード例：フラグによるスレッド制御
    1. 出力結果の例
  7. System.Threading.Volatileクラスの活用
    1. なぜVolatileクラスを使うのか？
  8. 注意が必要なメモリモデルの違い
  9. まとめ

volatileキーワードとは

C#における volatile キーワードは、フィールドの宣言時に使用される修飾子です。

このキーワードを付与されたフィールドは、「常に最新の値をメインメモリから読み書きする」 ことが保証されます。

通常、プログラムの実行効率を向上させるために、コンパイラやJIT（Just-In-Time）コンパイラ、さらにはCPU自体がコードの実行順序を入れ替えたり（再順序付け）、変数の値をレジスタにキャッシュしたりする最適化を行います。

シングルスレッド環境ではこれらの最適化は非常に有効ですが、マルチスレッド環境では「あるスレッドで行った変更が、別のスレッドからいつまでも反映されない」という問題を引き起こします。

volatileを使用することで、以下の2つの重要な効果が得られます。

  1. キャッシュの禁止：変数の値をCPUレジスタなどにキャッシュせず、常にメインメモリから読み込み、メインメモリへ書き込みます。
  2. メモリバリアの挿入：特定のメモリ操作の順序を制限し、コンパイラやCPUによる命令の入れ替えを防止します。

具体的には、volatileフィールドへの書き込みは「リリース・セマンティクス（Release semantics）」、読み込みは「アクワイア・セマンティクス（Acquire semantics）」を伴います。

これにより、書き込み前の操作が書き込み後に移動したり、読み込み後の操作が読み込み前に移動したりすることを防ぎます。

なぜvolatileが必要なのか：コンパイラ最適化とCPUキャッシュ

なぜ、明示的に volatile を指定する必要があるのでしょうか。

その理由は、現代のコンピューティング環境における「パフォーマンス最適化」にあります。

コンパイラによる最適化の例

例えば、以下のようなループ処理を考えてみましょう。

C#
bool _stop = false;

void Run()
{
    while (!_stop)
    {
        // 何らかの処理
    }
}

このコードを別のスレッドから _stop = true; と書き換えて停止させることを意図している場合、コンパイラは「このループ内で _stop は変更されていない」と判断し、以下のように最適化してしまう可能性があります。

C#
if (!_stop)
{
    while (true)
    {
        // 何らかの処理（無限ループ）
    }
}

このように最適化されると、後から別スレッドで _stop を書き換えても、実行中のスレッドはその変更を検知できず、無限ループに陥ります。

これが「可視性の問題」です。

volatile を付与することで、コンパイラに「この変数は外部から書き換わる可能性がある」と伝え、このような最適化を禁止できます。

CPUキャッシュとメモリモデル

また、ハードウェアレベルでも問題が発生します。

現代のCPUはコアごとに高速なキャッシュメモリ（L1/L2キャッシュなど）を持っており、メインメモリ（RAM）へのアクセスを最小限に抑えようとします。

スレッドAがある変数を書き換えても、その値がスレッドAのCPUキャッシュに留まり、スレッドBが参照しているメインメモリ上の値が更新されないという状況が発生し得ます。

volatile を使用すると、書き込み時にキャッシュの内容を強制的にメインメモリに反映させ（あるいは他コアのキャッシュを無効化し）、読み込み時に必ずメインメモリから最新のデータを取得するように動作します。

volatileの使い方と使用可能な型

C#で volatile を使用するには、フィールド定義の前にキーワードを記述します。

C#
public class Worker
{
    // volatileフィールドの宣言
    private volatile bool _shouldStop;

    public void RequestStop()
    {
        _shouldStop = true;
    }

    public void DoWork()
    {
        while (!_shouldStop)
        {
            // 作業を継続
        }
        Console.WriteLine("Worker thread: 停止します。");
    }
}

volatileを使用できる型

すべての型に対して volatile を指定できるわけではありません。

C#の仕様により、以下の型に制限されています。

  • 参照型（クラス、インターフェース、デリゲートなど）
  • ポインタ型（unsafeコンテキスト内）
  • sbyte, byte, short, ushort, int, uint, char, float, bool
  • ベース型が上記のいずれかである列挙型（enum）

注意点として、doubleやlong（64ビット整数）には直接volatileを適用できません。

これは、32ビット環境において64ビットデータの読み書きがアトミック（不可分）に行われない可能性があるためです。

これらの型で同様の効果を得るには、Interlocked クラスや、後述する Volatile 静的クラスを使用する必要があります。

volatileとアトミック操作の誤解

多くの開発者が陥る最大の誤解は、「volatileを使えばスレッドセーフになる」という考えです。

volatileはあくまで「可視性」を保証するものであり、「原子性（アトミック性）」を保証するものではありません。

複合操作の危険性

例えば、以下のコードはマルチスレッド環境において安全ではありません。

C#
private volatile int _counter = 0;

void Increment()
{
    _counter++; // スレッドセーフではない
}

一見、_counter++ は1つの操作に見えますが、実際には内部で以下の3つのステップが行われています。

  1. メモリから値を読み出す（Read）
  2. 値に1を加算する（Modify）
  3. メモリに値を書き戻す（Write）

2つのスレッドが同時に Increment を呼び出した場合、両方のスレッドが同じ「0」を読み出し、それぞれが「1」を計算して書き戻すと、結果として値は「1」にしかなりません（本来は「2」になるべきです）。

volatile は「読み出し」と「書き込み」を最新の状態で行うことは保証しますが、この Read-Modify-Writeの一連の流れを中断させない（アトミックに実行する）機能は持っていません。

このようなインクリメント操作を安全に行うには、lock 文を使用するか、Interlocked.Increment(ref _counter) を使用する必要があります。

lockやInterlockedとの使い分け

C#にはスレッド同期のための手段が複数用意されています。

状況に応じて最適なものを選択することが重要です。

機能役割パフォーマンス主な用途
volatileメモリ可視性の確保、最適化の抑制非常に高いフラグによる停止制御、ステータス確認
Interlocked特定の変数に対するアトミック操作高いカウンタの増減、値の入れ替え（CAS）
lock (Monitor)コードブロック全体の排他制御低い（オーバーヘッドあり）複雑なデータ構造の保護、一連の操作の保護

volatileを選ぶべきケース

volatileは非常に軽量ですが、機能が限定的です。

主に以下のようなシナリオで利用されます。

  • あるスレッドがフラグを立て、別のスレッドがそれをループ内で監視するような単純な通知。
  • 参照型のフィールドに対して、新しいインスタンスを一括で代入し、他スレッドに即座に公開する場合。

lockを選ぶべきケース

複数の変数が関連し合う操作や、リスト（List<T>）などのコレクションを操作する場合は、必ず lock を使用してください。

volatileでは「一貫性」を保つことはできません。

実践的なコード例：フラグによるスレッド制御

実際に volatile を使用して、安全にスレッドの実行を制御するコード例を見てみましょう。

この例では、メインスレッドからバックグラウンドタスクを停止させる仕組みを実装しています。

C#
using System;
using System.Threading;
using System.Threading.Tasks;

public class VolatileExample
{
    // 複数のスレッドからアクセスされるフラグ
    private volatile bool _isRunning = true;

    public void Execute()
    {
        Console.WriteLine("メインスレッド: 作業スレッドを開始します。");
        
        // 作業スレッドを起動
        Task workerTask = Task.Run(() => DoWork());

        // 2秒間待機
        Thread.Sleep(2000);

        Console.WriteLine("メインスレッド: 停止要求を出します...");
        _isRunning = false; // フラグを更新

        workerTask.Wait();
        Console.WriteLine("メインスレッド: 作業スレッドの終了を確認しました。");
    }

    private void DoWork()
    {
        long count = 0;
        // _isRunningがvolatileなので、最新の状態が常に読み込まれる
        while (_isRunning)
        {
            count++;
            if (count % 100000000 == 0)
            {
                Console.WriteLine("作業スレッド: 処理中...");
            }
        }
        Console.WriteLine("作業スレッド: ループを抜けました。");
    }
}

class Program
{
    static void Main()
    {
        var example = new VolatileExample();
        example.Execute();
    }
}

出力結果の例

メインスレッド: 作業スレッドを開始します。
作業スレッド: 処理中...
作業スレッド: 処理中...
メインスレッド: 停止要求を出します...
作業スレッド: ループを抜けました。
メインスレッド: 作業スレッドの終了を確認しました。

このプログラムにおいて、もし _isRunning に volatile が付いていない場合、Releaseビルドで実行すると DoWork メソッド内の while ループが最適化され、メインスレッドが値を false に書き換えても DoWork 側がそれを認識できず、永遠に「処理中…」と出力し続けるリスクがあります。

System.Threading.Volatileクラスの活用

.NETには、キーワードとしての volatile だけでなく、System.Threading.Volatile という静的クラスも用意されています。

このクラスは、特定の読み書き操作に対してピンポイントでvolatileセマンティクス（バリア）を適用したい場合に使用されます。

C#
int _sharedValue = 0;

// 書き込み（Volatile Write）
Volatile.Write(ref _sharedValue, 100);

// 読み込み（Volatile Read）
int val = Volatile.Read(ref _sharedValue);

なぜVolatileクラスを使うのか？

ローカル変数への適用

volatileキーワードはフィールドにしか指定できませんが、Volatileクラスは引数で渡された変数に対して操作を行うことができます。

doubleやlongへの対応

doubleやlongといった64ビット型はキーワードで指定できませんが、アトミックかつvolatileな読み書きをサポートします。

内部実装はプラットフォームにより異なりますが、安全に抽象化されています。

柔軟な設計

常にvolatileとして扱いたいわけではなく、特定の場所でのみ同期が必要な場合に限定して使用することで、コードの意図を明確にできます。

現代的なC#開発においては、言語キーワードの volatile よりも、この Volatile クラスや Interlocked を明示的に呼び出す手法が好まれる傾向にあります。

注意が必要なメモリモデルの違い

.NETのメモリモデルは、実行されるプラットフォーム（CPUアーキテクチャ）によって挙動が異なる場合があることに注意してください。

x86 / x64アーキテクチャ

強力なメモリモデルを持ち、ハードウェアレベルで多くの順序保証が行われます。

そのため、volatileを忘れていても偶然正しく動作することが多く、潜在的な並行性の問題が隠れやすいです。

ARMアーキテクチャ（Apple Siliconやモバイル端末）

弱いメモリモデルを持ち、命令の入れ替えがより積極的に行われます。

結果として、x86で動作していた不完全なマルチスレッドコードがARM環境に移行した途端にバグとして表面化することが多いです。

クラウド環境やモバイル環境を考慮すると、「特定のCPU環境で動くから大丈夫」という考えは非常に危険です。

共有変数へのアクセスには、必ず volatile、Interlocked、または適切な同期プリミティブを使用する習慣をつけましょう。

まとめ

C#の volatile キーワードは、マルチスレッドプログラミングにおける「メモリ可視性」を確保するための重要な道具です。

コンパイラやCPUの過剰な最適化を防ぎ、常に最新の値をスレッド間で共有できるようにします。

本記事の要点を振り返ります。

  • volatileの役割：変数のキャッシュを禁止し、命令の入れ替え（リオーダリング）を抑制する。
  • 可視性と原子性の違い：volatileは「最新の値が見えること」を保証するが、「一連の操作が中断されないこと（アトミック性）」は保証しない。
  • 制限事項：doubleやlongなどの型には使用できず、これらには Volatile クラスや Interlocked が必要。
  • 使い分け：単純なフラグ管理には volatile、数値の計算には Interlocked、複雑な状態管理には lock を選択する。

マルチスレッド環境でのバグは再現性が低く、デバッグが極めて困難です。

volatileの特性を正しく理解し、適切な同期手法を選択することで、堅牢でパフォーマンスの高いアプリケーションを構築しましょう。