I always use this, it allows lazy initialisation of generics, instead of creating a new singleton class for each type of singleton I want. It's also threadsafe but does not use locks on every access.

public static class Singleton<T> where T : class, new()
{
    private T instance = null;

    public T Instance
    {
        get
        {
            if (instance == null)
                Interlocked.CompareExchange(ref instance, new T());

            return instance;
        }
    }
}

If you're unfamiliar with the interlocked class, it performs atomic operations in a manner which is often quicker than a lock. Three possible cases:

1. First access by a single thread. Probably roughly the same performance as the obvious method using a lock

2. First access by many threads at the same time. Many threads might enter the interlocked exchange, in which case several items may get constructed but only 1 will "win". So long as your constructor has no global side effects (which is really shouldn't) behaviour will be correct. Performance will be slightly less than a lock, because of multiple allocations, but the overhead is small and this is a very rare case.

3. Later accesses. No locking or interlocked operations, this is pretty much optimal and is obviously the majority case.

I always use this, it allows lazy initialisation of generics, instead of creating a new singleton class for each type of singleton I want. It's also threadsafe but does not use locks on every access.

public static class Singleton<T> where T : class, new()
{
    private T instance = null;

    public T Instance
    {
        get
        {
            if (instance == null)
                Interlocked.CompareExchange(ref instance, new T(), null);

            return instance;
        }
    }
}

If you're unfamiliar with the interlocked class, it performs atomic operations in a manner which is often quicker than a lock. Three possible cases:

1. First access by a single thread. Probably roughly the same performance as the obvious method using a lock

2. First access by many threads at the same time. Many threads might enter the interlocked exchange, in which case several items may get constructed but only 1 will "win". So long as your constructor has no global side effects (which is really shouldn't) behaviour will be correct. Performance will be slightly less than a lock, because of multiple allocations, but the overhead is small and this is a very rare case.

3. Later accesses. No locking or interlocked operations, this is pretty much optimal and is obviously the majority case.