Чи безпечна нитка статичного конструктора C #?

Іншими словами, чи безпечний цей потік реалізації Singleton:

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

    static Singleton()
    {
        instance = new Singleton();
    }

    public static Singleton Instance
    {
        get { return instance; }
    }
}

Гарантовано, що статичні конструктори будуть запущені лише один раз у домені програми, перш ніж створюватись будь-які екземпляри класу або мати доступ до будь-яких статичних членів. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

Показана реалізація є потоковою безпекою для початкової побудови, тобто для конструювання об'єкта Singleton не потрібно блокування або тестування нуля. Однак це не означає, що будь-яке використання екземпляра буде синхронізовано. Існують різноманітні способи, як це можна зробити; Я показав один нижче.

public class Singleton
{
    private static Singleton instance;
    // Added a static mutex for synchronising use of instance.
    private static System.Threading.Mutex mutex;
    private Singleton() { }
    static Singleton()
    {
        instance = new Singleton();
        mutex = new System.Threading.Mutex();
    }

    public static Singleton Acquire()
    {
        mutex.WaitOne();
        return instance;
    }

    // Each call to Acquire() requires a call to Release()
    public static void Release()
    {
        mutex.ReleaseMutex();
    }
}

Хоча всі ці відповіді дають однакову загальну відповідь, є один застереження.

Пам'ятайте, що всі потенційні похідні родового класу складаються як окремі типи. Тому будьте обережні, застосовуючи статичні конструктори для загальних типів.

class MyObject<T>
{
    static MyObject() 
    {
       //this code will get executed for each T.
    }
}

Редагувати:

Ось демонстрація:

static void Main(string[] args)
{
    var obj = new Foo<object>();
    var obj2 = new Foo<string>();
}

public class Foo<T>
{
    static Foo()
    {
         System.Diagnostics.Debug.WriteLine(String.Format("Hit {0}", typeof(T).ToString()));        
    }
}

У консолі:

Hit System.Object
Hit System.String

Використання статичного конструктора насправді є безпечним для потоків. Статичний конструктор гарантовано виконується лише один раз.

Із специфікації мови C # :

Статичний конструктор для класу виконується не більше одного разу в заданій області додатків. Виконання статичного конструктора ініціюється першим із наступних подій, що відбудуться в домені програми:

• Створюється екземпляр класу.
• Будь-який із статичних членів класу посилається.

Так що так, ви можете довіряти, що ваш одиночний код буде правильно встановлений.

Zooba висловив чудову думку (і за 15 секунд до мене теж!), Що статичний конструктор не гарантуватиме безпечний для потоків спільний доступ до одиночного. З цим потрібно вирішити іншим способом.

Ось версія Cliffnotes з наведеної вище сторінки MSDN на c # singleton:

Завжди використовуйте таку схему, ви не можете помилитися:

public sealed class Singleton
{
   private static readonly Singleton instance = new Singleton();

   private Singleton(){}

   public static Singleton Instance
   {
      get 
      {
         return instance; 
      }
   }
}

Окрім очевидних функцій сингтона, він надає вам ці дві речі безкоштовно (стосовно сингтона в c ++):

1. ліниве будівництво (або ніяке будівництво, якщо його ніколи не називали)
2. синхронізація

Статичні конструктори гарантовано спрацьовують лише один раз у домені програми, тому ваш підхід повинен бути нормальним. Однак він функціонально не відрізняється від більш стислої, вбудованої версії:

private static readonly Singleton instance = new Singleton();

Безпека ниток є більшою проблемою, коли ви лінь ініціалізуєте речі.

Статичний конструктор закінчить роботу, перш ніж будь-який потік буде дозволений для доступу до класу.

    private class InitializerTest
    {
        static private int _x;
        static public string Status()
        {
            return "_x = " + _x;
        }
        static InitializerTest()
        {
            System.Diagnostics.Debug.WriteLine("InitializerTest() starting.");
            _x = 1;
            Thread.Sleep(3000);
            _x = 2;
            System.Diagnostics.Debug.WriteLine("InitializerTest() finished.");
        }
    }

    private void ClassInitializerInThread()
    {
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() starting.");
        string status = InitializerTest.Status();
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() status = " + status);
    }

    private void classInitializerButton_Click(object sender, EventArgs e)
    {
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
    }

Код, наведений вище, дав результати нижче.

10: ClassInitializerInThread() starting.
11: ClassInitializerInThread() starting.
12: ClassInitializerInThread() starting.
InitializerTest() starting.
InitializerTest() finished.
11: ClassInitializerInThread() status = _x = 2
The thread 0x2650 has exited with code 0 (0x0).
10: ClassInitializerInThread() status = _x = 2
The thread 0x1f50 has exited with code 0 (0x0).
12: ClassInitializerInThread() status = _x = 2
The thread 0x73c has exited with code 0 (0x0).

Навіть незважаючи на те, що статичний конструктор зайняв багато часу, інші потоки зупинилися і чекали. Усі потоки зчитують значення _x, встановлене внизу статичного конструктора.

Специфікації Common Language Infrastructure гарантує , що «тип ініціалізатор повинен працювати рівно один раз для будь-якого даного типу, якщо явно не викликається кодом користувача.» (Розділ 9.5.3.1.) Отже, якщо у вас є якийсь хитрий IL на вільному виклику Singleton ::. Cctor безпосередньо (малоймовірно), ваш статичний конструктор запуститься рівно один раз до використання типу Singleton, буде створено лише один екземпляр Singleton, і ваше властивість Instance захищено потоками.

Зауважте, що якщо конструктор Singleton звертається до властивості Instance (навіть опосередковано), то властивість Instance буде нульовою. Найкраще, що ви можете зробити, це виявити, коли це трапиться, і викинути виняток, перевіривши, що цей примірник не має значення в доступі до ресурсу. Після того, як ваш статичний конструктор завершить, властивість Instance буде недійсною.

Як вказує відповідь Zoomba , вам потрібно буде зробити Singleton безпечним для доступу з декількох потоків або застосувати механізм блокування навколо, використовуючи екземпляр singleton.

Щоб бути педантичним, але немає такого поняття, як статичний конструктор, а скоріше ініціалізатори статичного типу, ось невеличка демонстрація циклічної залежності статичного конструктора, що ілюструє цей момент.

Статичний конструктор гарантовано захищений від різьби. Також перегляньте дискусію про Singleton на DeveloperZen: http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code -1-обговорення /

Хоча інші відповіді в основному правильні, є ще один застереження зі статичними конструкторами.

Як зазначено в розділі II.10.5.3.3 Раси і тупиків в інфраструктурі ECMA-335 Common Language

Сама ініціалізація типу не повинна створювати глухий кут, якщо якийсь код, викликаний з ініціалізатора типів (прямо чи опосередковано) явно не викликає операції блокування.

Наступний код призводить до тупикової ситуації

using System.Threading;
class MyClass
{
    static void Main() { /* Won’t run... the static constructor deadlocks */  }

    static MyClass()
    {
        Thread thread = new Thread(arg => { });
        thread.Start();
        thread.Join();
    }
}

Оригінальний автор - Ігор Островський, дивіться його пост тут .