Take the 2-minute tour ×

While reading Jon Skeet's article on singletons in C# I started wondering why we need lazy initialization in a first place. It seems like the fourth approach from the article should be sufficient, here it is for reference purposes:

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

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static Singleton()


    public static Singleton Instance
            return instance;

In the rare circumstances, where you have other static methods on a singleton, lazy initialization may have benefits, but this is not a good design.

So can people enlighten me why lazy initialization is such a hot thing?

share|improve this question
Why do they call it "lazy initialization" anyway? It seems like doing it is anything but lazy, call it "Complicated Initialization", or "Problematic Initialization", or "Defect-Prone Initialization"... one of these would surly describe it more accurately ;) –  csharptest.net Nov 13 '09 at 1:31
Lazy initialization guarantees thread safety without the need for special thread safety constructs. [1]en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom –  code4life Apr 7 '10 at 1:27
Jon Skeet's article has moved to csharpindepth.com/Articles/General/Singleton.aspx. –  DPeden Feb 26 '12 at 22:16
add comment

4 Answers

up vote 3 down vote accepted

You don't need lazy initialization on a singleton, if the only reason you're going to use that type is to reference the instance.

If, however, you reference any other property or method on the type, or the type itself, you will initialize the singleton.

Granted, good design would leave one task for one type, so this shouldn't be a problem. If you make your singleton class to "complex", however, lazy initialization can help keep you from having consequences due to initializing too soon.

share|improve this answer
ok, so I am not crazy then. it just seems that everyone is obsessed with some form of lazy initialization where the reality is that the use case is almost non-existent. –  Lenik Nov 13 '09 at 0:59
Lazy initialization is incredibly useful as a general practice, just not necessarily for singletons. –  Reed Copsey Nov 13 '09 at 1:07
@Reed, totally agree. –  Lenik Nov 13 '09 at 1:13
add comment

In those scenarios where whatever it is you are initializing might not be needed at all, and is expensive to initialize, (in terms of CPU cycles or resources), then implementing a lazy initializor saves that cost in those cases where the object is not required.

If the object will always be required, or is relatively cheap to initialize, then there is no added benefit from a lazy initializer.

In any event, implementing a lazy initializer improperly can make a singleton non-thread-safe, so if you need this pattern, be careful to do it correctly. Jon's article has a pattern, (I think it's the last one), that addresses this issue.

share|improve this answer
Also note that in .NET 4, the preferred method will likely be to use System.Lazy<T> (msdn.microsoft.com/en-us/library/dd642331(VS.100).aspx) –  Pavel Minaev Nov 13 '09 at 0:13
my problem is that I don't see a use case for lazy initialization -- we always need to initialize a singleton class if we decide to use it, however, if we don't call methods that use singleton object, it does not get created, so I don't see a use case. –  Lenik Nov 13 '09 at 0:20
@Lenik, that sounds like you don't need (and shouldn't) use lazy initialier - not a problem. –  Charles Bretana Nov 13 '09 at 0:29
@Charles, I don't see how anyone needs it. even if I don't use lazy initialization, I still effectively get it since the static property won't get initialized unless I am actually using it. –  Lenik Nov 13 '09 at 0:33
@Lenik, What if someone makes a reference to your class to use some other property or class member that does not need whatever object is being initalized on demand lazilly? Even in a Singleton, (not that this would be good design) but what if the singleton class has a static utility method? It might get called in cases where the Singleton instance is not needed at all... If you initialze the singleton instance in a static initializer, it would get initialized unecessarilly. –  Charles Bretana Nov 13 '09 at 1:11
show 4 more comments

I'm not sure that this applies to C# as well, but I'll answer for C++:

One of the ideas behind Singletons is that the order of initialization of static objects is undefined. So if you have a static class that tries to use another static class, you might be in trouble.

A concrete example: Let's say I have a Log class, which I decided to implement as a Singleton. Let's also assume I have a method called LoadDB, which for whatever reason, is a static called at the start of the program. Assuming LoadDB decides it needs to log something, it will call the Singleton. But since the order of static initialization is undefined, it might be doing something that's an error.

A Singleton fixes this, since once you call GetInstance(), no matter where you are in the initialization process, the object is guaranteed to exist.

Again, I don't know if this is relevant, but at least that's the history of it (as far as I remember).

share|improve this answer
add comment

From Java DI perspective, lazy initialization is good, there are always (say, spring) beans in another API that you might not want to use, for example, an eagerly loaded singleton cache (something that is shared with everyone using the cache) might not be needed for you although it may be referred as a dependency in your same code. Whats the point in loading the singleton wasting resources?

The lazy initialization implementation choice is tricky, in spring, would you choose lazy-init="true" (spring eagerly instantiates singletons), an init-method/destroy-method, @PostConstruct, InitializingBean - afterPropertiesSet() method or return same spring instance in a getInstance() method?

The choice is a tradeoff of testability over reusability outside the spring container.

share|improve this answer
Also, tricky is where would you initialize your resources, in the constructor? or in another method that is invoked by the container that returns the same instance each time? –  user251779 Aug 31 '10 at 23:41
Also, tricky is where would you initialize your resources, in the constructor? or in another method that is invoked by the container that returns the same instance each time? In the case of delegating instantiation, calling initialize(), to spring, unit testing requires explicitly calling initialize() to get a valid instance. Spring, for example, allows creating a singleton using a private constructor, but allows initializing as late as someone calls a getInstance() on this instance. This pushes the initialization into another method rather than a constructor but how would you test/mock? –  user251779 Aug 31 '10 at 23:52
add comment

Your Answer


