Реализация синглтонов в .NET: Field-like vs. Lazy

Недавно один из читателей задал вопрос по поводу разницы между двумя реализациями синглтонов: через обычное статическое поле или же через статическое поле, содержащее Lazy<,T>,: public class FieldLikeSingleton
{
// Вариант C# 6
public static FieldLikeSingleton Instance { get, } = new FieldLikeSingleton(),
private FieldLikeSingleton() {}
}
public class FieldLikeLazySingleton
{
private static readonly Lazy<,FieldLikeLazySingleton>, _instance =
new Lazy<,FieldLikeLazySingleton>,(() =>, new FieldLikeLazySingleton()),
public static FieldLikeLazySingleton Instance =>, _instance.Value,
private FieldLikeLazySingleton() {}
}

Для простоты, первую реализацию я буду называть field-like реализацией (*), а вторую ленивой.

Существует 2 ключевых отличия в поведения этих двух реализаций, о которых нужно знать заранее. Для некоторых классов или приложений разница может оказаться несущественной, но для других она может быть критической.

(*) Название field-like уходит корнями в существующую терминологию, как например, field-like events. Да, с C# 6, field-like реализация теперь содержит свойство, но классическая реализация была основана именно на закрытом поле.

Все различия происходят из-за того, что в первом случае тело конструктора синглтона вызывается в статическом конструкторе, а во-втором случае в статическом конструкторе вызывается лишь конструктор объекта Lazy<,T>,, а сам объект создается при первом обращении.

1. Время инициализации объекта-синглтона

• Field-like синглтон будет проинициализирован при вызове статического конструктора (а не только при обращении к свойству Instance).
• Правила, определяющие время инициализации типа довольно запутаны. Например, при отсутствии явного статического конструктора синглтон может быть проинициализирован перед вызовом метода, в котором он может использоваться (подробнее об этом в статье О синглтонах и статичечских конструкторах).

Вот небольшой пример:class FieldLikeSingleton
{
public static FieldLikeSingleton Instance { get, } = new FieldLikeSingleton(),
private FieldLikeSingleton()
{
Console.WriteLine('FieldLikeSingleton.ctor'),
}
public void Foo()
{
Console.WriteLine('Foo'),
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine('Inside Main()'),
if (args.Length == 42)
{
Singletons.FieldLikeSingleton.Instance.Foo(),
}
}
}

При запуске в релизе, на экране нас ждут:

FieldLikeSingleton.ctor
Inside Main()

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

2. Проблемы с исключениями

• Исключение, возникшее в конструкторе field-like синглтона будет обернуто в TypeLoadException.
• Конструктор field-like синглтона будет вызван только один раз.
• В случае исключение тип синглтона окажется в нерабочем состоянии

Это наиболее ключевое отличие между ленивой и field-like реализацией. В случае field-like синглтона исключения в конструкторе являются по сути фатальными. Когда статический конструктор генерирует исключение, то весь тип помечается невалидным: любое обращение завершается с TypeLoadException (внутри которого будет храниться исходное исключение):class FieldLikeSingleton
{
public static FieldLikeSingleton Instance { get, } = new FieldLikeSingleton(),
private FieldLikeSingleton()
{
throw new DataException('Oops!'),
}
public void Foo()
{
Console.WriteLine('Foo'),
}
}
class Program
{
static void Main(string[] args)
{
try
{
FieldLikeSingleton.Instance.Foo(),
}
catch (TypeLoadException e)
{
// e.InnerException is of type DataException
Console.WriteLine(e.InnerException),
}
Console.WriteLine('Done'),
}
}

Исключение, завернутое в TypeLoadException, по сути, становится необрабатываемым. Мы можем перехватить его в высокоуровневом catch(Exception), но там мы точно ничего не сможем с ним сделать. Наш тип является невалидным и любое обращение даже к любому статическому члену приведет к исключению. По сути, исключение в конструкторе такого синглтона должно приводить к прекращению работы приложения, поскольку его нормальная работа невозможна.

Ленивый синглтон этой проблемой не обладает: если конструктор такого синглтона упадет в первый раз, то поле _instance останется непроинициализированным и при следующем обращении к синглтону будет еще одна попытка инициализации.

Так что выбрать?

Понятно, что исключения в конструкторах синглтонах это дело нехорошее, но ведь далеко не всегда очевидно, может оно произойти или нет. А если произойдет, то будет ли оно восстанавливаемым или временным (transient)? Если это критическое исключение, то тут все просто: в любом случае нужно крэшить приложение, надеясь на то, что в логах будет полное сообщение, а не лишь свойство Message.

Если же исключение является временным (конструктор обращается к файлу или другому ресурсу, который может быть временно недоступен), то ленивый синглтон позволит восстановить работу приложения, а field-like нет. Это может быть особенно важным в случае сервисов, который сможет восстановить свою работу в одном случае, и не сможет в другом.

Я практически всегда отдаю предпочтение ленивой версии. Она на одну строку длиннее, но это небольшая цена за более вменяемый стек исключений в случае ошибки в конструкторе. Если же Lazy<,T>, недоступен (используется более старая версия фреймворка), то для простых типов я использую field-like синглтон, а для сложных старый добрый double-checking lock.

Дополнительный ссылки

О синглтонах и статичечских конструкторах