这两个Singleton实现之间的区别

Question

I am learning how to implement some basic design patterns. Whilst learning the Singleton pattern I have noticed that there are two common implementations on the web:

// Possibly from: http://www.yoda.arachsys.com/csharp/singleton.html
// I cannot remember exact source, sorry :(

public sealed class Singleton
{
    // Static members are 'eagerly initialized', that is,
    // immediately when class is loaded for the first time.
    // .NET guarantees thread safety for static initialization
    private static readonly Singleton instance = new Singleton();

    // Private constructor prevents instantiation from other classes
    private Singleton() { }

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

    // Get the instance of the singleton
    public static Singleton getInstance()
    {
            return instance;
    }

}

and:

public class Singleton
{
  // Static, VOLATILE variable to store single instance
  private static volatile Singleton m_instance;

  // Static synchronization root object, for locking
  private static object m_syncRoot = new object();

  // Property to retrieve the only instance of the Singleton
  public static Singleton Instance
   {
      get
      {
          // Check that the instance is null
          if (m_instance == null)
          {
              // Lock the object
              lock (m_syncRoot)
              {
                  // Check to make sure its null
                  if (m_instance == null)
                  {
                      m_instance = new Singleton();
                  }
              }
          }

          // Return the non-null instance of Singleton
          return m_instance;
      }
  }
} 

1. In what scenario would you opt to have eagerly initialized vs lazy initialized?
2. Is the comment in the first example correct in saying that the initialization is thread safe? (I know it says it is, but it's the internet...)

Answer 1

I definitely would go with your first implementation...

the second seems questionable to me... if you need/want a lazy implementation you could use Lazy<T> for that - since it is part of the framework it feels much more comfortable..

BTW: There are even more ways to implement the Singleton pattern... here is an excellent article .

Answer 2

I'm not sure but it looks like you got those examples from here: http://www.yoda.arachsys.com/csharp/singleton.html

If not, read through it. There are a couple of thoughts on the two versions. If you ask me personally: I would go for the 2nd solution if I needed to know if the singleton has already been initialized or not.

If you don't have to deal with multithreading, I would use an even simpler approach (see the "Bad Code" examples in the references link).

Answer 3

The first one is safe and lazy.

static constructor s are guaranteed to be executed only once, and immediately before the first access to Instrance . If there is a static constructor(even if empty) then static field initializations are guaranteed to execute directly before the static constructor. If there is no static constructor, field initialization may occur earlier.

---

The second one is lazy, but I'm not sure if the double-lock pattern is valid like this. I suspect that it is broken, at least in the ECMA memory model.

---

Personally I'd avoid any Class.Instance singleton pattern in favour of IoC singletons in most situations.

Answer 4

1) that's entirely a design choice. Init up front or init when required.

2) Yes, it is thread safe as the CLR guarantees single threaded object initialisation. (static and instance)

EDIT

personally, in the first example, I make the Instance field public and dispense with the getter. Be interested to know if there is any reason that this is a bad idea?

Answer 5

It's a singleton so I'd go for option 1, unless it's a massive object that's not always even needed. But I probably would not make a singleton for something that's often not used at all.

Answer 6

Both implementations are fine, so it depends on what you need.

If performance is not an issue, use the eagerly created instance of the first one. Otherwise, use the second one, in which only the first access is synchronized.